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I. 


INTRODUCTION 


A.  BACKGROUND 

During  the  1990s,  Presidents  George  H.  W.  Bush  and  Bill  Clinton  recognized  that 
the  efficiency  of  government’s  business  processes  and  information  systems  had  fallen 
drastically  behind  the  processes  and  systems  that  were  being  used  in  the  private  sector. 
To  overcome  the  gap,  the  heads  of  state  began  to  push  toward  the  adoption  of  private 
industries’  business  processes  and  systems  via  legislation.  The  first  target  for 
transformation  was  the  government’s  financial  management  systems. 

In  1990,  the  Chief  Financial  Officers  (CFO)  Act  was  passed  and  24  executive 
branch  officials  were  established  and  charged  with  the  modernization  of  the  financial 
management  systems  of  the  major  U.S.  Departments.  These  included  the  Department  of 
Defense  (DOD),  the  Department  of  Commerce,  the  Department  of  Energy,  the 
Environmental  Protection  Agency,  the  National  Science  Foundation,  the  Nuclear 
Regulatory  Commission,  etc.  The  goal  of  the  CFO  Act  is  for  the  government  agencies  to 
generate  financial  statements  that  resemble  the  statements  produced  by  private 
companies. 

The  CFO  Act  of  1990  was  followed  by  the  Federal  Financial  Management 
Improvement  Act  of  1996  (FFMIA)  which  built  upon  the  CFO  Act  and  recommended 
government  agencies  employ  Automated  Information  Systems  (AIS)  capable  of 
producing  reliable,  useful,  and  timely  information  to  improve  decision  making  and 
accurately  maintain  accountability  of  government  funds  down  to  the  transaction  level  [1]. 
In  1996,  all  of  the  agencies  addressed  by  the  FFMIA  knew  that  systems  capable  of 
delivering  this  type  of  information  could  not  be  found  within  the  government.  Thus,  they 
turned  to  the  commercial  sector’s  key  technologies  to  comply  with  the  FFMIA  [1], 

Also  passed  in  1996  was  the  Information  Technology  Management  Reform  Act 
(ITMRA).  The  ITMRA  resulted  in  the  establishment  of  a  DOD  Chief  Information 
Officer  who  was  charged  with  managing  the  department’s  investment’s  in  information 
technology  assets  [2],  It  is  a  position  that  is  mirrored  in  the  commercial  sector  and  exists 
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to  ensure  that  all  technology  purchases  are  aligned  to  ensure  interoperability  and 
contribute  to  the  strategy  of  the  organization. 

It  is  clear  from  the  wording  of  the  legislation  passed  and  the  positions  that  were 
created  in  the  early  to  mid  1990s,  that  the  government  was  looking  to  industry  for 
answers  as  to  how  IT  would  renew  its  business  processes  and  financial  information 
systems.  From  industry,  the  answer  would  come  in  the  form  of  configurable  information 
systems  known  as  Enterprise  Resource  Planning  systems  (ERPs). 

B.  CURRENT  AIS  ENVIRONMENT  OF  THE  DOD 

The  pressure  to  renovate  the  business  processes  and  systems  of  the  DOD  brought 
about  by  legislation  is  external  to  the  department  itself.  There  is  additional  internal 
pressure  for  change  coming  from  the  military  leadership  because  of  the  operational  pain 
of  using  antiquated  processes  and  information  systems. 

While  the  civilian  leadership  was  mainly  concerned  with  accurately  tracking 
dollars  in  the  early  1990s,  the  military  leadership  was  focusing  on  business  processes 
because  of  the  logistical  problems  they  experienced  in  the  first  Gulf  War.  A  hallmark  of 
that  engagement  was  that  the  units  that  were  in  need  of  supplies  could  not  get  them  in  a 
timely  and  efficient  manner.  The  problem  with  the  logistical  pipeline  did  not  stem  from  a 
lack  of  equipment  in  the  area  of  operations;  rather,  the  problem  resulted  from  an  inability 
to  identify  and  distribute  the  massive  amounts  of  equipment  in  a  timely  manner  [3]. 

At  the  time  of  the  first  Gulf  War,  the  trend  in  commercial  logistics  was 
streamlining  supply  chains,  however,  the  DOD  was  not  a  part  of  this  trend.  Instead,  the 
DOD  opted  for  the  mass  inventory  supply  methodology  which  meant  that  everything  that 
might  possibly  be  used  was  sent  into  theater.  Once  there,  the  processes  for  getting  the 
supplies  to  those  in  need  were  complex  within  the  individual  services  and  there  was 
virtually  no  interoperability  between  the  services.  The  end  result  was  pallets  of  unused 
equipment  awaiting  return  to  the  U.S.  at  the  end  of  the  war.  Upon  seeing  the 
consequences  of  the  mass  inventory  approach,  the  Generals  in  charge  coined  the  phrase 
“iron  mountains”  to  describe  the  stacked  rows  of  cargo  boxes  filled  with  unused 
equipment  and  supplies.  The  “iron  mountains”  and  a  failure  to  support  troops  on  the  field 
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of  battle  troubled  the  DOD  leadership.  It  was  decided  then  that  the  DOD  had  to  change 
the  way  it  performed  Supply  Chain  Management  (SCM). 

The  first  step  in  the  DOD’s  SCM  transformation  was  the  identification  of  the  root 
causes  of  the  “iron  mountains.”  Investigating  the  causes  led  to  the  determination  that  the 
ineffectiveness  of  the  DOD’s  supply  chains  was  the  result  of  two  problems:  obsolete 
supply  chain  management  policies  and  outdated  information  systems  that  supported  those 
policies.  Both  problems  would  need  to  be  remedied  to  move  the  logistical  capabilities  of 
the  DOD  closer  to  the  capabilities  of  the  commercial  sector  [3],  Adding  to  the  problems 
that  needed  to  be  overcome,  there  was  also  the  civilian  leadership’s  FFMIA  requirement 
that  the  DOD  produce  auditable  financial  records. 

Traditionally,  the  DOD  had  looked  to  in-house  programmers  to  write  the  code  for 

business  system  software  [4],  Yet,  by  the  time  the  causes  of  the  “iron  mountains”  were 

defined  in  the  mid  1990s,  the  environment  surrounding  the  DOD  had  changed.  The 

Federal  Acquisition  Streamlining  Act  (1994)  and  Federal  Acquisition  Reform  Act  (1996) 

had  been  signed  by  President  Clinton.  This  legislation  reduced  the  amount  of  oversight 

for  contracts  with  the  private  sector  thereby  encouraging  outsourcing  to  the  commercial 

sector.  Moreover,  in  the  Quadrennial  Defense  Review  of  1997,  Clinton’s  Secretary  of 

Defense  (SECDEF)  William  Cohen  directed  the  DOD  to  accept  the  business  practices  of 

industry  to  shape  the  business  process  changes  that  needed  to  take  place  in  the 

department.  Due  to  the  fact  that  approval  for  the  funding  for  the  SCM  and  financial 

systems  transformation  projects  would  have  to  go  through  the  SECDEF ’s  office,  the 

military  leadership  took  Cohen’s  command  to  heart  and  went  to  the  private  sector  to 

explore  the  options  on  how  the  modernization  objectives  could  be  met.  Industry 

presented  two  options:  develop  custom  software  that  meets  the  requirements  or  use  ERP 

software.  The  first  option  was  deemed  impractical  because  of  cost  and  the  nature  of  the 

DOD.  Developing  custom  software  is  a  solution  that  is  reserved  for  organizations 

looking  for  the  competitive  advantage  that  a  custom  logistics  software  suite  can  provide 

[4],  This  customization  comes  with  an  extraordinarily  high  price  tag  and  the  organization 

that  chooses  this  path  should  not  be  one  that  is  adverse  to  risk  and  change.  The  DOD  was 

looking  to  play  “catch-up”  with  industry.  Furthermore,  the  DOD  is  a  case  study  in  risk 

avoidance  and  adversity  to  change  [4],  Ultimately,  these  factors  led  to  the  judgment  that 
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the  second  option  of  contracting  for  ERP  software  is  the  preferred  course  of  action  and 
the  separate  service  components  (Army,  Navy,  Air  Force  and  Marine  Corps)  along  with 
Defense  Logistics  Agency  (DLA)  went  their  separate  ways  on  that  path. 

Today  the  DOD  is  at  a  midway  point  on  the  course  toward  ERP  releases 
throughout  the  department  to  include  DLA.  All  of  the  enterprise  systems  are  at  different 
points  in  the  development  phase  and  the  DOD  as  a  whole  is  awaiting  the  results  to  see  if 
the  ERP  endeavors  will  improve  or  possibly  resolve  the  problems  of  the  current  processes 
and  systems  that  continue  to  plague  the  organization  to  date. 

During  current  operations  in  Afghanistan  and  Iraq  in  support  of  the  Global  War 
on  Terror,  the  forces  in  battle  encounter  the  same  difficulty  with  logistics  that  their 
predecessors  in  the  first  Gulf  War  faced.  Those  in  need  go  without  while  unidentified 
supplies  continue  to  get  stockpiled.  Logisticians  are  in  an  operating  environment  where 
they  support  a  unified  force  but  they  pull  equipment  from  five  different  sources  of 
supply.  All  sources  lack  the  visibility  that  is  vital  for  encouraging  confidence  in  the 
system.  This  lack  of  confidence  leads  to  continuous  re-orders  which  leads  to  more 
stockpiling  and  waste.  The  inefficiencies  of  the  defense  logistics  systems  remain  the 
same  because  the  systems  are  still  in  need  of  a  common  architecture  and  common 
processes  [5].  Accordingly,  the  financial  accountability  these  systems  produce  has  not 
changed  and  the  DOD  remains  noncompliant  with  the  FFMIA.  It  is  the  hope  of  the 
services  and  DLA  that  their  separate  ERPs  individually  and  collectively  will  resolve  the 
existing  crisis. 

C.  STATEMENT  OF  REQUIREMENT 

Billions  of  dollars  have  been  and  will  continue  to  be  invested  in  the  DOD  ERP 
programs  [1],  At  a  time  when  the  U.S.  is  actively  engaged  in  costly  combat  operations  in 
the  Middle  East  and  is  in  desperate  need  of  updating  its  aging  equipment,  the  military  can 
not  afford  to  have  these  programs  fall  short  of  their  stated  objectives.  More  importantly, 
the  future  logistical  capabilities  and  legislative  compliance  of  the  DOD  will  be 
determined  by  the  success  or  failure  of  these  initiatives.  Thus,  it  is  important  that  the 
plans  that  are  being  executed  for  the  implementation  and  integration  of  these  ERPs  are 
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analyzed  thoroughly.  This  research  is  a  comparative  study  of  the  different  service’s  ERP 
strategies  to  reveal  the  similarities  and  differences  of  the  individual  plans. 

1.  Research  Questions 

To  conduct  this  research,  the  following  questions  will  be  explored: 

•  What  is  an  ERP? 

•  By  industry’s  standards,  what  is  the  optimal  way  to  implement  an  ERP? 

•  How  does  an  ERP  integrate  business  processes  that  are  not  part  of  the 
standardized  software  suite? 

•  What  are  the  experiences  and  plans  of  the  individual  DOD  ERP  programs? 

•  What  are  the  lessons  learned  to  date  that  will  assist  the  DOD  in  achieving 
the  joint  vision  for  the  ERP  programs? 

D.  BENEFITS  OF  THE  STUDY 

This  research  is  ongoing  while  the  DOD  is  still  in  the  early  stages  of 
implementation  as  a  whole.  The  purpose  of  the  research  is  to  gain  an  understanding  of 
the  decisions  that  are  being  made  throughout  the  force  to  enhance  the  cooperation  among 
the  services.  To  be  truly  enterprise  wide,  each  of  these  ERPs  are  going  to  have  to  be 
integrated  with  one  another  at  some  point  in  the  future  [5],  If  this  integration  is  never 
achieved,  then  the  DOD  will  have  five  more  non-integrated  legacy  systems  that  do  not 
contribute  to  the  joint  warfighting  capability  of  the  force.  Thus,  it  is  the  goal  of  this  study 
to  aid  this  future  integration  by  revealing  the  differences  between  the  programs  and  the 
obstacles  to  implementation  that  have  to  be  overcome  to  make  these  systems  successful. 
Benchmarking  the  programs  against  each  other  and  against  industry  best  practices  will 
provide  the  military  leadership  a  reference  for  making  the  decisions  that  will  improve  the 
likelihood  for  success. 

E.  SCOPE  OF  THESIS 

The  scope  of  this  investigation  is  to  assess  how  the  ERP  programs  might  be  able 
to  improve  the  joint  capability  of  the  services  and  where  they  might  fall  short.  To  do  this, 
it  will  focus  on  bringing  together  the  different  works  that  have  been  completed  on  the 
DOD  ERPs.  It  will  examine  the  ERP  programs  of  the  Defense  Logistics  Agency  (DLA), 
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the  US  Army,  Navy,  Air  Force,  and  Marine  Corps  to  discover  what  the  programs  are 
doing  communally  and  what  they  are  doing  individually. 


F.  METHODOLOGY 

The  thesis  will  use  a  literature  review  and  interview  methodology  to  gather 
information  about  ERP  implementations  in  the  private  and  public  sectors.  Literature  to 
better  understand  ERP  applications  in  general  will  be  examined  to  define  what  an  ERP  is 
and  the  potential  they  have  to  reduce  cost  and  increase  capabilities.  For  the  DOD  ERP 
programs  specifically,  a  combination  of  literature  reviews  and  interviews  will  be 
conducted. 

G.  ORGANIZATION  OF  THE  THESIS 

Chapter  II  will  present  the  history  of  ERP.  It  will  also  cover  the  potential  benefits 
and  hazards  of  an  ERP  implementation  as  well  as  the  steps  that  should  be  taken  to 
migrate  from  the  legacy  environment. 

Chapter  III  provides  an  overview  of  the  separate  DOD  ERP  programs.  A 
synopsis  of  how  each  of  the  programs  came  about  will  be  given.  Additionally,  the 
current  state  and  cost  of  the  programs  will  be  explored. 

Chapter  IV  analyzes  the  similarities  and  differences  between  the  differing 
approaches  of  the  separate  services  and  DLA.  The  results  of  the  study  will  be  drawn 
form  this  analysis. 

Chapter  V  concludes  the  thesis  by  identifying  the  barriers  that  must  be  overcome 
to  make  these  programs  a  success.  Several  recommendations  as  to  how  these  barriers 
might  be  overcome  will  be  presented.  Lastly,  some  additional  areas  of  research  will  be 
opened  up. 
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II.  ENTERPRISE  RESOURCE  PLANNING 


A.  HISTORY  OF  ERP 

Proprietary  systems  that  are  developed  by  an  organization’s  in-house  or 
contracted  software  developers  are  generally  referred  to  as  legacy  systems.  These 
systems  are  designed  using  the  overarching  principal  that  whatever  business  processes 
are  done  without  the  use  of  a  computer  can  be  replicated  in  software.  Automating 
processes  that  were  formerly  done  manually  provides  a  benefit  in  that  it  decreases  the 
amount  of  time  it  takes  to  complete  the  same  process.  Written  in  high-level 
programming  languages  such  as  FORTRAN  and  COBOL,  legacy  systems  are  the  first 
stage  in  the  evolutionary  history  of  computers  in  the  workplace  [6]. 

The  problem  with  legacy  systems  is  that  they  are  developed  to  meet  particular 
functions.  This  design  philosophy  causes  fragmentation  between  the  disparate  functional 
areas.  Systems  that  support  a  particular  functional  area  but  do  not  integrate  with  other 
systems  are  commonly  referred  to  as  “stovepipes”  [7].  Since  stovepiped  systems  are 
often  in  need  of  the  same  data,  the  result  is  the  data  is  maintained  in  several  different 
locations  to  service  the  separate  systems.  Fragmentation  and  a  lack  of  integration 
between  the  disparate  systems  often  result  in  problems  with  the  consistency  of  the  data 
residing  in  the  different  locals.  Data  may  be  updated  in  one  system  but  the  change  does 
not  take  effect  and  is  not  visible  in  the  other  systems  that  are  also  maintaining  that  data. 
The  coordination  and  communication  problem  that  is  the  consequence  of  this  framework 
is  severely  detrimental  to  the  organizations  that  operate  in  this  way  because  users  have  to 
take  extra  time  to  validate  data  in  order  to  guarantee  the  reliability  of  the  information 
being  produced  from  the  data  [8], 

ERP  grew  out  of  the  foundation  laid  by  legacy  systems  as  an  answer  to  the 
problems  of  non-integrated  systems.  In  the  1970s  software  engineers  began  to  realize 
that  data  transcends  functional  area  [8].  Additionally,  they  began  to  capitalize  on  the 
commonalities  that  existed  between  the  business  processes  of  different  manufacturing 
companies  independent  of  the  end  products  that  were  being  produced  by  those 
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companies.  They  did  this  by  creating  packaged  software  that  was  designed  to  be  used  in 
any  manufacturing  environment  with  little  modification. 

1.  Materials  Requirements  Planning 

The  predecessor  of  ERP  is  known  as  Material  Requirements  Planning  (MRP).  It 
is  a  software  package  developed  in  the  1970s  as  a  simulation  tool  to  answer  the  questions 
in  the  universal  manufacturing  equation.  Manufacturing  firms  operate  under  the 
principals  of  the  universal  manufacturing  equation  which  asks  [8]: 

•  What  are  we  going  to  make? 

•  What  does  it  take  to  make  it? 

•  What  do  we  have? 

•  What  do  we  have  to  get? 

For  the  companies  who  elected  to  purchase  an  MRP,  the  logic  built  into  the  software  uses 
models  of  available  capacity  in  the  manufacturing  plant  and  linear  scheduling  to  produce 
a  master  schedule  which  satisfies  the  “what  are  we  going  to  make”  question.  To  handle 
the  “what  does  it  take  to  make  it”  question,  MRP  uses  a  bill  of  materials  which  details  all 
the  components  that  go  into  whatever  is  being  made.  Calculations  of  lead-times  to 
receive  those  components  are  in  the  software  for  the  scheduling  of  purchase  orders  that 
must  be  made  to  get  the  components  in  time  for  production.  This  takes  care  of  the  “what 
do  we  have  to  get”  question  and  the  “what  do  we  have”  question  is  resolved  with  an 
inventory  database  in  the  MRP  [9]. 

2.  Closed-Loop  MRP 

After  their  release,  MRPs  were  quickly  altered  to  closed-loop  MRPs  with  the 
added  capability  of  inputting  changes  in  delivery  schedules  from  the  suppliers  of  sub¬ 
components.  With  the  updated  delivery  schedules,  a  closed-loop  MRP  is  capable  of 
comparing  the  new  delivery  date  and  the  date  that  the  components  are  required  to  enter 
production.  The  comparison  highlights  the  situations  where  the  components  are  not 
going  to  arrive  as  scheduled  [10].  Feeding  back  delivery  schedules  into  the  MRP  is  the 
reason  for  the  loop  portion  of  the  new  name.  The  feedback  loops  which  allow  the  input 
of  updates  to  reflect  the  reality  of  the  changing  supply  environment  are  used  by  the 
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capacity  planning  tool  that  was  also  upgraded  in  closed-loop  MRPs.  Plant  scheduling 
functionality  was  improved  so  that  priorities  in  production  can  be  modified  based  upon 
the  information  that  is  coming  in  on  the  feedback  loops.  The  feedback  functionality 
characteristics  of  closed-loop  MRPs  are  diagramed  below. 


Figure  2. 1 .  Closed-Loop  MRP  System  Showing  Feedback  (From:  [11]) 

3.  MRP  II 

In  1975,  MRPs  got  more  improvements  and  another  new  name.  The  name 
changed  to  Manufacturing  Resource  Planning  with  an  abbreviated  name  of  MRP  II. 
Manufacturing  replaced  materials  as  the  first  word  in  the  new  name  because  the 
advancements  with  MRP  II  allow  the  user  to  plan  all  aspects  of  manufacturing  including 
personnel,  machines  and  inventory.  The  two  additional  components  that  provide  MRP 
this  capability  are  tools  that  capture  all  the  cost  and  sales  information  of  the  plant  and 
simulation  tools  that  allow  the  user  to  change  different  aspects  of  the  production  plan  to 
perform  “what-if  ’  analysis  that  can  then  be  acted  upon  [12]. 

4.  ERP 

During  the  technology  boom  of  the  1990s,  MRP  II  was  expanded  beyond 
manufacturing  floor  by  incorporating  customer  relations  modules,  human  resources 
information,  facilities  management,  and  accounting  into  the  common  database  repository 
of  the  software.  Today’s  ERP  is  an  enterprise  wide  system  that  integrates  all  aspects  of 
what  an  organization  does  and  delivers  current  cross-functional  information  to  every 
department  and  supply  chain  member  in  the  organization. 
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Figure  2.2.  The  ERP  Wheel  (From:  [4]) 


5.  ERP  II 


The  current  movement  in  the  world  of  information  technology  (IT)  is  to  branch 
out  of  the  enterprise  and  link  the  organizational  systems  to  the  companies  that  business  is 
conducted  with.  Using  the  internet  or  electronic  data  interchange  (EDI),  organizations 
are  sharing  the  data  in  their  central  ERP  repositories  with  the  trusted  companies  in  the 
supply  chain.  Not  only  are  companies  sharing  data,  they  are  also  sharing  business 
processes  and  shattering  the  barriers  to  information  that  traditionally  existed  between 
interacting  organizations.  This  contemporary  free-flow  of  information  between 
organizations  that  are  fusing  separate  enterprise  systems  is  called  ERP  II  [13]. 

Companies  that  interact  in  this  manner  are  operating  under  what  is  known  as  the 

“web-like”  value  chain  concept  [4],  The  hallmark  of  the  concept  is  that  the  systems  of 

the  separate  organizations  are  integrated  so  that  the  information  held  by  the  systems  is 

visible  to  the  employees,  customers,  suppliers,  and  trading  partners  who  are  held 

responsible  for  acting  on  this  information.  Not  only  are  the  systems  integrated,  but  the 

business  processes  between  the  organizations  are  automated.  This  automation  eliminates 

the  phones,  faxes,  and  e-mails  that  have  been  traditionally  used  to  conduct  transactions 

10 


and  chase  down  the  most  current  information.  Instead,  all  parties  involved  have  total 
access  to  the  updated  information  about  the  dynamic  events  and  transactions  that  are 
occurring  within  and  between  the  separate  organizations.  In  industry,  companies  that 
operate  in  the  “web-like”  value  chain  are  referred  to  as  real  time  enterprises  because  they 
are  acting  on  the  most-current  information  available  from  their  integrated  business 
systems  [14]. 

B.  EXPECTED  BENEFITS  OF  AN  ERP 

When  an  organization  successfully  implements  an  ERP,  the  benefits  it  can  expect 
include  [15]: 

1.  Cycle  time  reduction  ERP  can  provide  substantial  benefits  in  terms  of 
cost  and  time  reduction  in  key  business  processes. 

2.  Faster  information  transactions  An  ERP  can  deliver  a  reduction  in  the 
time  to  enter  pricing  information  from  five  days  to  five  minutes. 

3.  Better  financial  management  One  of  the  basic  functions  of  ERP  systems 
is  managing  financial  information  across  the  enterprise. 

4.  Laying  the  groundwork  for  e-Commerce  Centralized  data  in  an  ERP 
system  facilitates  linkage  to  e-Commerce  systems. 

5.  Making  tacit  process  knowledge  explicit  Key  processes,  decision  rules, 
and  information  structures  are  well  understood  and  documented  in  an  ERP 
system. 

These  benefits  are  compounded  when  an  organization  becomes  a  real  time  enterprise  and 
transparency  is  achieved  across  all  the  companies  in  the  supply  chain.  A  quality  ERP 
implementation  allows  every  department  to  know  exactly  what  every  other  department  is 
doing.  Adopting  ERP  II  and  opening  ERPs  to  the  other  organizations  in  the  supply  chain 
permits  every  department  throughout  the  separate  organizations  to  know  what  resources 
are  available  for  use  at  all  times.  When  a  company  takes  this  action  it  is  extending  the 
enterprise  and  the  information  that  is  produced  results  in  profitable  decision  making  [16]. 

1.  Shortened  Timeline 

The  expected  benefit  of  having  an  integrated  database  that  facilitates  the 
transparent  flow  of  information  throughout  an  enterprise  and  between  interacting 
enterprises  is  the  primary  reason  for  choosing  an  ERP  system.  It  is  this  capability  that 
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brings  about  improved  business  processes  and  increased  profitability.  Yet,  there  is  an 
additional  reason  for  electing  ERP  in  that  it  shortens  the  timeline  associated  with 
software  development. 


Requirements  Analysis  .  Testing  &  Operating 

Definition  &  Design  eve  °Pmen  Implementation  &  Maint. 


Time 

Figure  2.3.  ERP  Implementation  (From:  [4]) 

An  ERP  is  software  and  because  it  is,  all  of  the  phases  of  software  development 
from  requirements  definition  to  operations  and  maintenance  must  be  gone  through  to  get 
the  system  up  and  running.  The  time  it  takes  go  through  the  phases  is  abbreviated  due  to 
the  fact  that  the  ERP  for  each  individual  organization  is  developed  using  a  generic 
template  that  models  the  way  work  should  be  performed  in  that  particular  industry.  For 
example,  if  the  company  performing  the  implementation  is  a  manufacturing  company,  the 
manufacturing  template  will  be  used.  If  it  is  a  distribution  company,  then  that  template 
will  be  the  starting  point.  In  addition  to  the  templates  for  the  commercial  sector  there  are 
also  ERP  templates  for  educational  and  government  institutions.  Since  the  requirements 
of  the  industry  or  organization  are  known  and  built  into  the  template,  the  time  it  takes  to 
do  analysis  and  design  along  with  system  development  can  be  dramatically  shortened 

[17]. 
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C.  VENDORS 

Today’s  ERP  market  is  divided  into  two  levels  of  suppliers:  large-scale  and  small- 
scale.  Capturing  approximately  64  percent  of  the  total  ERP  market  revenue  are  the  three 
large-scale  suppliers  SAP,  Oracle  Corporation,  and  Baan  International  [4],  The 
remaining  36  percent  of  the  market  is  spread  among  the  smaller  ERP  companies  that 
produce  specialized  ERPs  for  particular  industries. 

Five  former  IBM  employees  founded  SAP  and  created  the  first  ERP.  As  the 
originator  of  ERP  technology,  SAP  holds  the  top  position  among  ERP  providers  and 
controls  30%  of  the  market.  Behind  SAP  is  the  Oracle  Corporation  with  24%  of  the 
market.  Oracle  has  established  a  high  market  share  because  of  its  advantages  in 
scalability  and  better  coordination  with  suppliers  and  customers  [18].  It  also  increased  its 
market  share  after  performing  a  hostile  takeover  of  the  PeopleSoft  Inc.  in  January  of  2005 
[19].  The  takeover  provided  Oracle  with  the  9%  of  the  ERP  market  that  was  previously 
held  by  PeopleSoft.  Companies  that  concentrate  on  global  operations  tend  to  choose 
BAAN  International  because  of  its  modules  that  link  the  monetary  and  technological 
requirements  of  the  various  countries  operated  in  [18]. 

D.  SUCCESS  STORIES 

Several  of  the  best  run  and  most  successful  companies  in  the  world  run  ERP 
software  and  those  companies  that  are  looking  to  continue  those  successes  are  making  the 
transition  to  being  ERP  II  organizations.  It  has  been  reported  that  over  sixty  percent  of 
U.S.  Fortune  1000  companies  run  an  ERP  [20].  Many  of  these  companies  made  the 
transition  to  an  ERP  prior  to  the  year  2000  to  achieve  Y2K  compliance.  Within  the 
companies  that  elected  ERP  for  Y2K  compliance,  the  decision  was  made  to  buy  the  latest 
packaged  software  on  the  market  vice  trying  to  fix  the  Y2K  problems  residing  in  their  old 
computer  systems.  It  is  a  good  thing  that  the  companies  did  make  the  transition  because 
by  integrating  the  data  throughout  the  organization,  these  companies  have  been  able  to 
speed  up  processes,  improve  communication,  and  make  better  decisions.  The  result  is  a 
position  amongst  the  U.S.  Fortune  1000  companies  and  more  satisfied  customers  yielding 
bigger  profit  margins. 
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1. 


General  Electric 


An  example  of  an  industrial  giant  that  moved  to  an  ERP  in  the  1990s  is  General 
Electric  (GE).  With  roughly  300,000  employees  worldwide  GE  is  an  industrial  behemoth 
that  does  everything  from  making  jet  engines  to  managing  financial  portfolios.  GE 
implemented  an  Oracle  ERP  and  received  all  of  the  expected  benefits  from  the 
implementation  including  cycle  time  reductions,  faster  information  transactions,  better 
financial  management,  and  e-Commerce  expansion.  Furthermore,  when  most  companies 
were  drastically  reducing  their  investments  in  IT  after  the  bursting  of  the  “dot-com 
bubble”  in  2001,  GE  increased  IT  spending  by  twelve  percent  in  2002.  The  increase  was 
caused  by  the  Chief  Executive  Officer,  Jeff  Immelf  s  belief  that  GE  needed  to  move 
beyond  ERP  to  ERP  II.  The  company  desires  to  digitize  every  business  process  that 
could  be  digitized  internal  and  external  to  the  company.  It  is  an  initiative  that  has  paid 
off  and  continues  to  pay  off.  Aided  by  the  ERP  II  initiative,  between  2002  and  2006,  the 
company’s  consolidated  revenue  grew  from  $112  to  $163  billion  [21]  and  in  2006,  GE 
ranked  first  overall  in  Fortune  Magazine’s  “America’s  Most  Admired  Companies”  [22], 

2.  The  United  States  Mint  and  Strategic  Petroleum  Reserve 

ERP  has  been  proven  to  work  as  well  in  public  organizations  as  it  does  in  private 
entities.  In  1998,  a  bureau  of  the  Department  of  Treasury,  the  U.S.  Mint  implemented  an 
SAP  ERP  system  to  replace  the  multiple  legacy  systems  it  was  running.  The  Mint  is  a 
unique  public  sector  organization  because  it  is  self-funded  and  profit-driven.  It  generates 
profit  by  selling  coins  to  collectors.  Prior  to  1998,  the  legacy  systems  run  in  the  Mint 
were  incapable  of  properly  handling  the  planning,  tracking,  inventory  and  scheduling  of 
the  raw  materials  that  go  into  producing  coins.  Packaging  and  delivery  of  the  coins 
following  production  was  also  inadequate  with  only  half  of  customer’s  orders  being 
shipped  within  eight  weeks  of  purchase  [23].  The  accuracy  and  timeliness  of  financial 
and  management  information  was  an  issue  as  well.  Problems  with  the  mint’s  information 
systems  did  not  end  inside  the  organization.  There  was  no  interface  to  connect  the  1.1 
million  coin  collecting  customers  to  the  mint’s  IT  systems.  The  only  way  customers 
could  purchase  coins  was  through  a  mail  order  catalog  or  at  three  retail  kiosks  [23].  It 
resulted  in  profits  that  were  well  below  what  they  could  have  been.  To  fix  the  problems 
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with  the  internal  processing  systems,  the  ERP  was  the  first  thing  to  be  implemented. 
After  the  ERP  was  up  and  running,  an  on-line  retail  site  was  established  in  1999  to 
interface  to  the  customers.  Both  endeavors  were  a  resounding  success.  In  total,  the 
projects  cost  $40  million  with  a  projected  seven-year  savings  of  $80  million. 
Additionally,  in  1999  revenue  increased  by  51.9%  over  1998  as  a  result  of  the  popularity 
of  the  e-commerce  site  [2], 

In  the  same  timeframe  that  the  U.S.  Mint  was  migrating  from  the  legacy 
environment  to  an  ERP,  another  Federal  agency,  the  Strategic  Petroleum  Reserve  (SPR) 
was  also  making  the  switch.  Established  following  the  OPEC  oil  embargo  of  the  1970s, 
the  purpose  of  the  SPR  is  to  store  and  maintain  an  inventory  of  crude  oil  as  a  deterrent  to 
oil  import  cutoffs.  The  SPR  also  provides  an  emergency  stock  of  oil  in  the  event  that  it  is 
needed  for  national  defense  [24], 

SAP  was  selected  as  the  vendor  to  provide  an  ERP  solution  to  the  SPR  in  1997.  It 
was  determined  that  the  SPR  needed  to  change  their  information  systems  because  it  was 
experiencing  the  traditional  problems  that  occur  with  legacy  systems.  The  same  data 
existed  in  numerous  locations  and  the  confusion  that  resulted  was  hampering  mission 
performance.  The  SAP  ERP  was  up  and  running  in  March  of  1999  and  the  eight  legacy 
systems  of  the  SPR  were  turned  off.  Like  the  results  at  the  Mint,  the  SPR’s  ERP  was  a 
triumph  and  achieved  98%  of  the  organizational  goals  that  were  established  at  the  outset 
of  the  project  [25].  A  year  after  going  live  on  their  ERP,  the  SPR  advertised  a  47%  return 
on  the  $10  million  ERP  investment  [2], 

E.  CRITICISMS  OF  ERP 

Along  with  the  proponents  and  success  stories  supporting  ERP  systems,  there  are 
also  many  critics  and  ERP  failures.  Criticism  is  not  misplaced  since  the  statistics 
covering  IT  project  failure  rates  are  not  encouraging.  In  1997,  the  consulting  firm  KPMG 
questioned  Canada’s  leading  1,450  public  and  private  sector  organizations.  The  intent  of 
the  questionnaire  published  was  to  figure  out  the  reasons  behind  the  failure  of  IT  projects. 
Over  61%  of  the  projects  analyzed  in  the  study  were  reported  as  failures  [26], 
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1.  The  Boston  Consulting  Group  and  Robbins-Gioia  Surveys 

More  recently,  two  other  surveys  were  conducted  specifically  addressing  ERPs. 
The  first  of  these  was  completed  by  the  Boston  Consulting  Group  in  the  year  2000.  After 
surveying  100  executives  of  leading  companies  about  their  ERP  initiatives,  they  found 
that  only  one  out  of  every  three  executives  considered  the  initiative  a  success  [27].  These 
results  were  supported  by  the  survey  of  another  consulting  firm  in  2001.  Robbins-Gioia 
LLC  conducted  the  same  type  of  questionnaire  survey  about  the  perception  of 
organizations  with  regard  to  their  ERP  package  implementations.  A  total  of  232 
organizations  responded  and  36%  of  the  respondents  had,  or  were  in  the  process  of 
implementing  an  ERP.  Of  the  enterprises  that  had  experience  with  an  ERP  system  [26]: 

•  51%  viewed  their  ERP  implementation  as  unsuccessful. 

•  46%  of  the  participants  noted  that  while  their  organization  had  an  ERP 
system  in  place,  or  was  implementing  a  system,  they  did  not  feel  their 
organization  understood  how  to  use  the  system  to  improve  the  way  they 
conduct  business. 

•  56%  of  survey  respondents  noted  their  organization  has  a  program 
management  office  (PMO)  in  place,  and  of  these  respondents,  only  36% 
felt  their  ERP  implementation  was  unsuccessful. 

There  is  a  bias  in  both  of  these  surveys  because  they  are  based  upon  perceptions 
of  the  ERPs  and  they  do  not  take  into  account  if  the  ERPs  cited  as  unsuccessful  achieved 
the  goals  established.  Additionally,  if  the  survey  respondents  were  not  part  of  the 
implementation  team  and  the  systems  were  forced  upon  them,  they  are  inherently  going 
to  have  a  pessimistic  view  of  the  ERP  [26].  Despite  these  facts,  the  surveys  are  a  good 
demonstration  of  the  fact  that  the  odds  of  success  are  not  stacked  in  favor  of  the  ERP. 
Thus,  ERP  project  managers  must  be  aware  of,  and  attempt  to  avoid  the  pitfalls 
associated  with  ERP  failures. 

2.  Pitfalls  of  ERP  Implementations 

With  the  multitudes  of  ERP  implementations  (both  successful  and  unsuccessful) 
occurring  over  the  last  two  decades,  there  has  been  plenty  of  opportunity  to  discover  and 
define  the  ERP  pitfalls  that  should  be  avoided.  Prior  to  going  into  what  those  pitfalls  are, 
it  is  important  to  delineate  what  constitutes  a  partial  and  total  ERP  failure.  Different 
criteria  for  partial  failure  include  [After:  28]: 

16 


1 .  Not  making  the  promised  return  on  investment, 

2.  Inordinately  extending  the  implementation  schedule  and  start-up  date, 

3.  Running  over  budget  by  large  variances, 

4.  Grinding  the  organization  to  a  crawl  pace,  or  the  severest  of  all 
consequences, 

5.  Stopping  production  and/or  not  delivering  orders  to  your  customers. 

What  can  be  considered  a  total  failure  is  to  invest  large  sums  of  money  into  an  ERP  only 
to  find  that  the  organization  is  incapable  of  seeing  the  project  through  to  completion. 
Thus,  the  ERP  project  is  terminated  and  the  organization  finds  itself  back  at  the  starting 
point  with  nothing  to  show  for  the  resources  expended.  Such  a  tragedy  is  an  indication 
that  there  was  not  enough  research  into  what  would  be  required  of  the  organization  in  the 
transition  to  the  ERP  environment  [8]. 

In  order  to  prevent  having  a  partial  failure  or  a  total  failure,  an  organization  that  is 
planning  to  adopt  an  ERP  should  be  made  aware  of,  and  expend  every  effort  and  all 
resources  required  to  evade  the  pitfalls  and  consequences  summarized  in  Table  1. 
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Pitfall 

Definition 

Consequence 

( 1 .)  Overcustomization 

Every  organization  is  unique 
in  data  requirements  and 
business  processes. 
Customizations  transform 
packaged  ERP  software  into 
ERP  software  that  meets 
organizations’  individual 
business  processes  and 
operations. 

Long  and  expensive  customization  efforts 
often  result  in  the  pass  of  release  deadlines 
and  budget  overruns.  Customizations  may 
make  the  software  more  fragile  and  harder 
to  maintain  when  it  finally  goes  to 
production. 

(2.)  Lack  of  Top  Management 
Commitment 

The  delegation  of  the  ERP 
project  to  lower  management 
levels. 

Upper  management  is  ’’out  of  touch”  with 
critical  events  and  the  scope  of  the  project. 
This  results  in  a  lack  of  resources  being 
committed  to  the  project. 

(3.)  Resistance  to  Change/Lack  of 
Buy-in 

Lack  of  a  change  management 
program. 

A  lack  of  buy-in  often  results  from  not 
getting  end-users  involved  in  the  project 
from  the  very  start,  thereby  negating  their 
authorship  and  ownership  of  the  new  system 
and  processes. 

14.)  Inadequate  Requirements 
Definition 

Not  comprehensively  and 
systematically  developing  a 
quality  set  of  functional 
requirements  definitions. 

Poor  package  selection  resulting  in 
implementation  failure. 

(5.)  Poor  ERP  Package  Selection 

Inadequate  research  into 
whether  or  not  the  proposed 
system  will  meet  the  users 
needs. 

Implementation  failure. 

(6.)  Inadequate  Resources 

Attempting  to  save  money  by 
having  the  organization’s 
employees  implement  the 

ERP  on  an  overtime  basis. 

The  organization’s  employees  do  not  have 
the  skills  required  to  implement  the  software 
and  they  burn  out. 

17.)  Miscalculation  of  Time  and 
Effort 

The  miscalculation  of  effort 
and  time  it  will  take  to 
accomplish  the  project. 

ERP  project  is  doomed  to  failure. 

18.)  Misfit  of  Application  Software 
with  Business  Processes 

Not  examining  the  business 
processes  in  the  software  that 
is  going  to  conflict  with  the 
business  processes  of  the 
organization. 

A  failure  to  integrate  the  applications  with 
the  business  processes  causes  loss  of 
productivity  and  time,  and  ultimate  benefits. 

19.)  Unrealistic  Expectation  of 
Benefits  and  ROI 

Software  providers  are 
notorious  for  overstating  the 
benefits  in  terms  of  ROI, 
when  the  total  costs  of  the 
project  have  been  understated. 

No  chance  of  achieving  the  anticipated  ROI. 
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Pitfall 

Definition 

Consequence 

(10.)  Inadequate  Training  and 
Education 

ERP-related  training  is  crucial 
as  most  employees  must  learn 
new  software  interfaces  and 
business  processes  which 
affect  the  operation  of  the 
entire  enterprise. 

Shortchanging  this  part  of  the  ERP 
implementation  leads  to  much  pain  and 
suffering  downstream. 

(11.)  Poor  Project  Design  and 
Management 

Short-cutting  critical  events  in 
the  project  plan,  such  as  time 
for  documentation,  redefining 
and  integrating  processes,  or 
testing  before  "going  live." 

Weaknesses  and  opportunities  for 
improvement  are  not  identified. 

(12.)  Poor  Communications 

A  failure  to  announce  the 
reason  for  the  up  and  coming 
effort,  and  not  continuing  to 
advise  the  organization  of  the 
progress  and  importance  of 
the  ERP  implementation  to 
the  company. 

Different  parts  of  the  organization  will  not 
able  to  assess  how  they  will  be  impacted  by 
changes  in  processes,  policies,  and 
procedures. 

(13.)  Ill-advised  Cost  Cutting 

Going  live  at  multi-plant  sites 
simultaneously  or, 
unrealistically  compressing 
the  schedule  in  order  to  save 
on  expenses. 

Subjecting  all  plants  or  some  plants  to  a 
total  shutdown  should  there  be  a  false  start¬ 
up.  An  overrun  of  both  the  schedule  and  the 
budget. 

Table  1.  ERP  Pitfalls  and  Consequences  (After:  [28,  29]). 


One  of  the  most  commonly  cited  partial  failures  in  history  occurred  as  a  result  of 
a  company’s  inability  to  dodge  a  pitfall. 


3.  F ailure  at  Hershey  F oods 

In  1998,  the  leading  manufacturer  of  chocolates  in  the  United  States,  Hershey 
Foods  attempted  to  implement  an  SAP  ERP  with  consequences  that  cost  the  company 
tens  of  millions  of  dollars.  The  problem  at  Hershey  involved  pitfall  number  seven: 
miscalculation  of  time  and  effort.  Believing  that  the  company  could  push  into  the  final 
stages  of  implementation  during  a  peak  period  for  business  (right  before  Halloween),  the 
company  attempted  to  do  both.  The  truth  was  that  the  ERP  implementation  brought 
about  major  changes  to  Hershey’ s  business  processes  at  a  time  when  the  company  needed 
to  be  focusing  on  its  core  competency  of  producing  and  distributing  products. 
Unfortunately,  something  had  to  give  and  in  this  instance  it  was  the  production  and 
distribution  of  products.  The  result  was  that  for  Halloween  1999,  the  problems  with  the 
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ERP  prevented  the  delivery  of  $100  million  in  candy  and  Hershey’s  stock  price  fell  more 
than  8%  in  a  single  day  [30].  In  the  long  run,  what  happened  to  Hershey  was  only  a 
partial  failure.  The  company  recovered  from  the  loss  and  continues  to  produce  sugary 
treats.  Some  Wall  Street  financial  analyst  even  argue  that  the  company  does  it  better  now 
with  their  new  system. 

4.  The  Nestle,  Allied  Waste  and  K-Mart  Experiences 

Similar  to  what  happened  at  Hershey,  another  major  chocolate  producer,  Nestle 
also  had  significant  difficulties  with  their  ERP  implementation.  After  starting  an  SAP 
ERP  implementation  in  1997,  by  2000  the  company  was  facing  a  complete  collapse.  To 
blame  for  the  predicament  was  pitfall  numbers  three:  resistance  to  change/lack  of  buy-in. 
The  ERP  project  team  had  failed  to  include  the  key  stakeholders  who  would  be  most 
affected  by  the  new  business  processes  and  systems.  Thus,  when  the  ERP  was  rolled  out 
for  use  in  2000,  the  company  experienced  a  major  personnel  problem.  The  workers  who 
were  supposed  to  use  the  system  had  no  idea  how.  Their  ignorance  was  compounded  by 
the  fact  that  their  superiors  could  not  be  of  any  assistance  because  they  were  left  out  of 
the  project  as  well.  Fearing  the  worst,  the  company  stepped  back  from  the  $200  million 
project  midway  through  and  took  it  in  a  new  direction.  The  new  direction  was  to 
deemphasize  the  release  of  software  and  emphasize  management  of  the  change  that  the 
workers  were  going  to  experience  with  the  ERP.  Key  stakeholders  were  brought  into  the 
project  team  and  training  on  the  new  system  became  widespread.  Fortunately,  the  ERP 
team  at  Nestle  had  the  wisdom  to  shift  the  emphasis  because  by  2002,  the  company  was 
touting  a  $325  million  savings  from  their  ERP.  Hindsight  being  what  it  is,  at  the 
conclusion  of  the  ERP,  Nestle’s  team  leader  stated  that  “The  primary  lesson  taken  away 
from  the  project  is  this:  No  major  software  implementation  is  really  about  the  software. 
It’s  about  change  management”  [31]. 

Allied  Waste  Industries  and  the  retailer  K-Mart  were  not  as  fortunate  with  their 
ERPs  as  Hershey  and  Nestle.  After  spending  over  $40  million  on  an  SAP  ERP,  Allied 
Waste  declared  the  system  too  complex,  too  expensive  and  a  poor  fit  for  the  way  the 
company  does  business.  It  was  ruled  a  total  failure  and  the  company  wrote-off  the  $40 
million  as  a  loss  [32],  K-Mart  also  experienced  a  total  failure  with  their  ERP  and  had  to 
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write-off  a  $130  million  loss.  Total  failures  such  as  these  are  not  as  common  as  partial 
failures,  but,  they  are  included  as  evidence  of  the  worst  that  can  happen  if  the  pitfalls  of 
ERP  are  not  thoroughly  analyzed  and  prepared  for  prior  to  starting  the  project. 

F.  ERP  PAINS 

As  organizations  world-wide  move  away  from  systems  developed  “in-house” 
toward  the  packaged  software  of  ERPs,  studies  have  shown  that  what  happened  at 
Hershey  and  Nestle  is  the  norm  vice  the  exception  [30],  The  cost  and  publicity  of  the 
partial  failures  are  usually  not  as  dramatic  as  those  suffered  by  Hershey,  but  they  are 
almost  always  present  in  an  ERP  undertaking.  Commonly,  installation  of  the  software  is 
late  and  business  processes  suffer  for  approximately  six  months  [30].  These  problems 
that  have  become  the  standard  with  ERP  implementation  account  for  the  negative 
perceptions  that  were  revealed  in  The  Boston  Consulting  Group  and  The  Robbins-Gioia 
surveys.  Of  course,  there  are  exceptions  to  this  standard  because  some  organizations  can 
never  overcome  the  pitfalls  (Allied  Waste  and  K-Mart)  and  some  are  extraordinarily 
successful  at  managing  the  pitfalls  and  never  experience  the  pains  normally  associated 
with  ERP.  For  example,  the  Microsoft  Corporation  went  live  with  an  SAP  ERP  within 
seven  months  of  the  initial  planning  meetings  and  immediately  captured  the  benefits  of 
the  integrated  ERP  environment  [5].  Microsoft  is  the  worldwide  leader  in  computing 
software  so  familiarity  with  software  driven  initiatives  certainly  came  into  play. 
Nonetheless,  Microsoft  credited  the  success  with  their  ability  to  control  pitfall  number 
two:  lack  of  top  management  commitment.  Ultimate  responsibility  for  Microsoft’s  ERP 
implementation  rested  with  the  Chief  Operating  Officer  [5].  A  top  official  was  charged 
with  monitoring  the  implementation  schedule  and  his  visibility  in  this  role  emphasized 
the  importance  of  the  ERP  project  to  everyone  in  the  corporation. 

Instantaneous  success  with  ERP  like  what  was  experienced  at  Microsoft  is  the 
exception.  The  foundation  of  ERPs  is  that  business  processes  transcend  an  organization’s 
functional  areas.  It  follows  that  the  design  of  ERPs  is  standardized  with  the  best  business 
practices  and  processes  built-in  to  the  software.  Historically,  legacy  systems  are  built 
around  the  activities  of  different  functional  areas.  The  system  used  depends  upon  the 
department  that  the  worker  is  operating  in.  If  something  goes  wrong  outside  of  that 
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particular  department,  it  is  somebody  else’s  problem.  ERP  destroys  this  mentality 
because  the  people  in  the  different  departments  can  see  all  of  the  same  information. 
Thus,  the  accountability  that  is  required  of  all  the  departments  is  tested  in  an  ERP  like 
never  before.  If  a  department  is  not  operating  as  it  should  be,  it  is  going  to  immediately 
be  visible  to  all  the  other  departments  in  the  organization.  To  obtain  such  visibility  and 
business  process  integration,  the  organization  that  adopts  an  ERP  must  conform  to  the 
processes  that  are  resident  within  the  system.  This  entails  an  extensive  business  process 
reengineering  effort  due  to  the  fact  that  all  new  business  processes  will  be  put  in  place. 
Attempting  to  do  it  any  other  way  would  mean  trying  to  conform  the  ERP  to  fit  the  old 
way  of  doing  business  which  is  leads  to  pitfall  number  one:  overcustomization. 

1.  The  Role  of  Change  Management 

Business  process  reengineering  (BPR)  of  the  magnitude  required  by  the 
installation  of  an  ERP  mandates  that  the  organization  undergo  what  is  often  referred  to  as 
a  technochange.  The  term  techno  comes  before  change  because  it  is  a  change  that 
deliberately  uses  IT  to  transform  an  organization.  A  technochange  is  different  than  an  IT 
project  because  in  an  IT  project,  the  only  department  involved  in  the  project  is  the 
information  services  (IS)  department.  The  extent  of  an  IT  project  does  not  go  far  beyond 
upgrading  the  current  systems  or  IT  infrastructure  to  achieve  better  response  times  and 
performance.  A  good  example  of  an  IT  project  is  the  upgrading  of  servers.  While  such  a 
change  would  have  a  big  impact  on  the  IS  department,  it  would  generally  be  transparent 
to  the  system  users  except  for  the  improved  performance  the  users  experience  as  a  result 
of  the  upgrade. 

Technochange  uses  IT  to  alter  the  organization’s  behavior  and  has  an  impact  far 
beyond  the  IS  department.  In  a  technochange  initiative,  the  organization  has  elected  to 
use  technology  that  mandates  a  change  in  business  processes.  Consequently,  the  people 
who  use  the  new  IT  system  and  the  organization  as  a  whole  must  undergo  a  radical 
transformation.  This  type  of  transformational  change  using  IT  requires  more  than  just 
good  software  developers  and  programmers  who  can  produce  a  smooth  running  product. 
In  order  to  achieve  the  performance  improvements  that  technochange  products  (like 
ERPs)  advertise,  the  users  of  the  product  must  be  prepared  for  a  significant  divergence 


22 


from  their  current  processes.  It  is  this  requirement  that  causes  the  word  change  to 
encompass  the  second  half  of  the  phrase  technochange  [33]. 

Change  is  a  broad  expression  that  has  several  orders  of  magnitude.  There  are  big 
changes,  small  changes,  changes  that  take  several  years  and  changes  that  are  completed 
in  only  seconds  or  nanoseconds.  Beyond  orders  of  magnitude,  a  second  characteristic  of 
change  is  that  it  affects  virtually  everything.  Organizations  do  not  have  the  capacity  to 
escape  the  grasp  of  change  and  accordingly  they  fall  victim  to  it.  The  most  extreme 
change  an  organization  can  go  through  is  known  as  a  transformational  change. 
Transformational  change  requires  a  drastic  reconceptualization  of  the  way  work  should 
be  done  by  the  workers  undergoing  the  transformation  [34],  It  is  the  hardest  type  of 
change  because  it  requires  the  organization  to  disregard  the  past  and  work  toward  the 
leadership’s  vision  of  what  the  organization  should  look  like.  Due  to  the  scope  of  change 
that  is  brought  about  by  technochange  initiatives  such  as  an  ERP,  it  can  only  be  classified 
as  a  transformational  change.  Most  transformational  change  efforts  fail  because  of  the 
amount  of  effort  they  require  at  all  levels  of  the  organization.  Technochange  endeavors 
are  no  exception  to  this  rule  [33],  This  is  the  reason  that  the  statistics  involving  worker’s 
perception  of  ERP  initiatives  are  dramatically  pessimistic.  Reactions  to  changes  in 
organizational  business  processes  are  negative  because  the  changes  to  the  way  people 
work  in  an  ERP  are  drastic.  Even  when  the  ERP  does  what  it  was  designed  to  do  and 
does  it  well,  the  pain  of  the  change  that  is  experienced  by  the  organization  will  have  an 
inverse  relationship  to  the  cost  of  the  program.  However,  the  relationship  is  not  directly 
inverse;  the  most  pain  resulting  from  the  organizational  change  comes  after  the  majority 
of  the  spending  on  the  project  has  taken  place.  Thus,  the  real  barrier  to  seeing  the  project 
through  to  the  point  where  the  net  benefits  begin  to  get  realized  is  not  a  matter  of 
economics  but  a  matter  of  how  well  the  organization  can  manage  the  change  that  is 
taking  place. 
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Figure  2.4.  BPR:  In  it  for  the  Long  Run?  (From:  [35]) 

To  help  the  organization  through  the  pain  caused  by  the  change  takes  a  mastery  of 
pitfalls  two  (Lack  of  Top  Management  Commitment)  and  three  (Resistance  to 
Change/Lack  of  Buy-in).  Managing  pitfall  two  is  self  explanatory:  to  successfully 
transition  to  an  ERP,  the  change  can  not  be  driven  by  middle  managers.  The  leadership 
at  the  highest  level  of  the  organization  must  be  convinced  that  a  change  is  necessary  and 
commit  to  pushing  their  agenda  for  change.  Once  the  ERP  technochange  has  been  firmly 
established  as  the  leader’s  agenda,  that  leader  must  begin  to  foster  support/buy-in  for  the 
ERP.  A  technique  for  developing  a  consortium  of  supporters  for  the  change  is  to  surface 
a  mini  crisis  which  dictates  that  a  change  must  occur.  The  BPR  life  cycle  provides  a 
clear  demonstration  of  the  phases  of  a  technochange  initiative  with  regards  to  the 
organizational  resistance  that  must  be  met  and  overcome. 
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Figure  2.5.  BPR  Organizational  Life  Cycle  (From:  [36]) 

In  the  beginning  of  the  change,  a  “strong  man”  must  emerge  and  create  a  crisis 
that  demands  change.  For  example,  at  Microsoft,  the  “strong  man”  of  the  ERP  initiative 
was  the  Chief  Operating  Officer.  The  crisis  that  he  used  to  gain  support  for  the  decision 
to  transition  to  an  ERP  was  the  incredible  growth  that  the  company  was  experiencing  in 
2001.  A  growth  that  was  so  impressive  that  it  was  straining  the  financial,  operations,  and 
human  resources  systems  of  the  company.  ERP  was  chosen  as  the  solution  to  the 
problem  and  it  was  rapidly  implemented  [5]. 

In  this  case,  Microsoft  chose  an  authoritarian  approach  to  contend  with  the  BPR 
organizational  life  cycle.  A  top  leader  was  selected,  a  solution  was  chosen,  and  the 
technochange  was  pushed  through  with  little  time  for  opposition.  This  is  one  way  of 
countering  the  resistance  to  change  in  the  “struggle  for  power”  phase  of  the  life  cycle. 
Another  way  of  countering  resistance  is  to  create  buy-in.  An  approach  that  has  been 
developed  and  has  had  proven  success  at  creating  buy-in  is  known  as  prototyping.  This 
approach  involves  the  development  of  a  futuristic  model  of  how  the  system  will  work  and 
the  capabilities  that  it  will  bring  to  bear  as  a  demonstration  to  the  users  to  get  feedback  on 
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how  the  prototype  can  be  refined.  The  fact  that  the  users  also  get  to  work  with  the  system 
and  experience  its  functionality  firsthand  goes  a  long  way  toward  instilling  a  sense  of 
ownership  at  the  user  level  in  the  change  effort.  This  “grassroots”  support  can  be  a 
critical  ingredient  towards  a  project’s  success.  Prototyping  does  not  negate  the  need  for  a 
“strong  man”  but  it  can  be  used  by  the  “strong  man”  as  a  tool  vice  having  to  resort  to  a 
dictatorship  [33]. 

A  variation  of  the  prototyping  approach  is  a  pilot  project.  Pilots  entail  testing  an 
organizational  redesign  in  one  or  two  locations.  If  the  redesign  proves  its  value  in  those 
locations  then  it  can  be  employed  throughout  the  rest  of  the  organization.  Pilot  projects 
reduce  risk  by  proposing  easy  termination  if  it  is  determined  that  the  project  is  not  going 
to  meet  expectations  [33]. 

The  approach  that  an  organization  applies  to  steer  an  ERP  implementation 
through  the  BPR  organizational  life  cycle  is  not  as  important  as  the  life  cycle  itself.  An 
organization  can  use  prototyping,  pilot  projects,  or  an  authoritarian  approach  and  they  can 
all  be  equally  effective.  The  important  thing  is  that  when  it  comes  to  an  ERP  initiative, 
the  life  cycle  is  very  real.  People  do  not  like  change  and  the  organizational  change  that  is 
required  by  an  ERP  is  going  to  generate  resistance.  If  the  organization  does  not  follow 
the  life  cycle  and  counter  the  resistance  with  a  “strong  man”,  incremental  victories  and 
continual  improvements,  the  resistance  movement  will  prevent  success. 

2.  Cost 

Prior  to  phase  one  of  the  BPR  life  cycle  and  the  “strong  man’s”  announcement 
that  an  ERP  project  is  going  to  take  place,  resistance  to  the  project  will  appear  because  of 
the  cost.  With  an  average  total  cost  of  ownership  (TCO)  for  a  large  ERP  in  the  hundreds 
of  millions,  making  the  decision  to  acquire  these  systems  will  significantly  affect  the 
organization’s  bottom  line  [32],  The  TCO  includes  the  cost  of  the  hardware,  software, 
professional  services  and  staff,  but,  along  with  the  TCO,  there  are  also  hidden  costs  that 
potential  consumers  should  be  aware  of.  Many  of  these  hidden  costs  occur  because  of  a 
failure  to  manage  the  ERP  pitfalls.  Professionals  in  the  ERP  industry  cite  these  hidden 
costs  as  the  source  of  budget  overruns.  These  costs  result  from  [After:  17]: 
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1.  Training  -  Developing  a  curriculum  to  train  all  the  people  in  the 
organization  impacted  by  the  ERP  was  voted  the  number  one 
underestimated  budget  item. 

2.  Integration  and  testing  -  Integrating  the  ERP  with  the  other  software 
systems  the  organization  is  using  and  then  testing  those  links  can  be 
costly. 

3.  Customization  -  Losing  control  of  pitfall  number  one  and  transforming 
the  ERP  into  custom  software  will  definitely  overrun  the  budget. 

4.  Data  conversion  -  Moving  the  data  from  the  legacy  systems  to  the  ERP 
comes  with  a  high  price  tag. 

5.  Data  analysis  -  If  the  data  needs  in  the  ERP  needs  to  be  combined  for 
analysis  and  data  mining,  the  cost  of  the  tools  to  do  this  should  be 
projected. 

6.  Consultants  ad  infinitum  -  Be  wary  of  continually  increasing  the  number 
of  consultants  to  manage  the  project.  The  objectives  and  cost  of  the 
consultants  must  be  clearly  delineated  early-on. 

7.  Replacing  your  best  and  brightest  -  Employees  with  earned  skills  from  the 
ERP  implementation  will  be  in  high  demand.  Funds  must  be  available  to 
keep  these  people  or  replace  them  with  IT  workers  that  have  similar  skills. 
Replacing  them  will  cost  much  more  than  rewarding  them  appropriately. 

8.  Implementation  teams  can  never  stop  -  The  ERP  must  be  continually 
improved  upon  and  rejuvenated  as  demonstrated  in  the  BPR  life  cycle. 
Keeping  the  team  together  and  actively  improving  the  system  comes  with 
a  cost. 

9.  Waiting  for  ROI  -  The  return  on  an  ERP  will  not  be  noticeable  for  a  long 
time  after  implementation.  An  organization  must  be  financially  prepared 
to  wait. 

10.  Post-ERP  Depression  -  After  the  ERP  goes  live,  there  is  going  to  be  a 
drop  in  organizational  performance  while  people  get  accustomed  to 
working  with  the  new  system. 

With  such  a  high  TCO  and  the  significant  risk  of  budget  overrun  from  the  hidden 
costs,  resistance  is  going  to  build  because  there  will  be  those  that  wonder  what  the 
justification  could  possibly  be  for  embarking  upon  a  project  that  is  almost  guaranteed  to 
overrun  the  budget  and  has  the  potential  for  being  a  complete  disaster.  An  ERP  can  not 
be  defended  with  the  argument  that  it  provides  a  competitive  advantage  to  increase 
revenue.  A  competitive  advantage  is  provided  only  by  a  capability  that  one  organization 
has  that  competitors  can  not  gain  access  to.  For  example,  Wal-Mart’ s  IT  systems  can  not 
be  classified  as  legacy  because  of  the  huge  sums  of  money  that  the  company  spends  to 
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keep  their  systems  on  the  “cutting  edge”  in  SCM  processes  and  speed.  The  competitive 
advantage  of  the  company  resides  in  those  systems.  If  Wal-Mart  were  to  change  over  to 
an  ERP,  they  would  lose  that  competitive  advantage  and  they  would  be  on  a  level  playing 
field  with  every  other  discount  retailer.  ERPs  are  available  to  every  organization  willing 
to  pay  the  price  so  they  do  not  offer  a  competitive  advantage.  They  are  a  good  choice  for 
an  organization  that  does  not  quite  know  what  it’s  processes  are  and  is  therefore  looking 
for  a  software  package  to  implement  the  “best  practices”  of  the  ERP.  Utilizing  the 
software’s  processes  prevents  having  to  go  through  an  extended  systems  analysis  time 
trying  to  figure  out  what  the  organization’s  processes  are  and  then  analyzing  if  those  are 
the  processes  they  should  be  following  [4],  In  the  ERP’s  best  practices  lies  the  potential 
for  improved  internal  operations.  They  do  not  offer  competitive  advantage  but  they  do 
offer  the  potential  to  rise  to  a  level  of  service  that  has  become  the  standard.  If  an 
organization  is  functioning  extremely  well  without  an  ERP,  then  there  is  no  need  to  buy 
one.  However,  if  an  organization  finds  that  they  are  unable  to  track  customer  orders, 
coordinate  manufacturing  with  those  orders  and  is  carrying  an  excessive  amount  of 
inventory,  then  an  ERP  is  a  good  choice  [17].  The  most  successful  companies  in 
America  are  using  an  ERP.  A  fact  that  is  supported  by  the  following  statistics  [4]: 

•  7  of  10  Most  Profitable 

•  9  of  10  with  Highest  Market  Value 

•  7  of  Top  10  Pharmaceutical  Companies 

•  7  of  Top  10  Computer  Companies 

•  7  of  Top  10  Petroleum  Companies 

•  6  of  Top  10  Electronic  Companies 

•  8  of  Top  10  Chemical  Companies 

•  8  of  Top  10  Food  Companies 

With  these  statistics,  which  delineates  who  is  using  an  ERP,  a  company  that  can  not 
compete  with  the  companies  that  are  successfully  running  an  ERP  will  quickly  fall 
behind. 
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3. 


Alternative  to  ERP 


Thus,  the  question  becomes  what  is  the  alternative  to  an  ERP?  The  only 
alternative  to  adopting  an  ERP  is  to  develop  custom  software  and  attempt  to  build-in 
better  business  practices  than  what  is  contained  in  an  ERP.  There  are  several  problems 
with  this  alternative  which  increases  the  risk  and  cost  associated  with  it.  A  clear  fact  that 
has  already  been  established  is  that  people  do  not  like  change.  Consequently,  when  the 
software  development  life  cycle  begins  with  requirements  definition,  it  is  hard  to  define 
requirements  that  are  a  drastic  departure  from  the  current  business  processes.  The  biggest 
part  of  requirements  definition  is  asking  the  users  of  the  current  systems  what  the 
requirements  of  the  new  systems  should  be.  Unfortunately,  the  natural  tendency  of  users 
is  to  describe  the  way  they  currently  do  their  job  which  leads  to  the  old  business 
processes  being  established  as  the  requirements  of  the  new  system.  The  second  problem 
with  custom  software  is  the  amount  of  time  it  takes  as  compared  to  an  ERP 
implementation.  New  software  does  not  have  the  benefit  of  a  template  to  work  from  so 
everything  is  built  from  ground  zero.  This  substantially  increases  the  analysis  and  design 
phase  and  the  development  phase  of  the  life  cycle.  The  longer  a  project  exists  in  the 
developmental  stages  prior  to  implementation,  the  longer  the  resistance  movement  has 
time  to  build  against  it.  A  strengthened  resistance  force  can  eradicate  a  software  project 
faster  than  anything  else  [37].  Lastly  and  most  importantly,  ERPs  have  been  proven  to 
work.  Any  new  software  development  effort  can  not  make  this  claim.  While  the  chances 
of  having  a  completely  successful  ERP  are  not  great,  the  risk  of  a  total  failure  is  much 
higher  with  a  custom  software  project  [38]. 

4.  Customization  Risk 

Since  an  ERP  is  not  custom  software,  an  ERP  project  team  has  to  be  wary  of 
those  that  wish  to  turn  it  into  custom  software  thereby  destroying  the  value  of  the 
template.  After  the  cost  dispute  has  been  countered  with  a  demonstrated  necessity,  the 
next  source  of  resistance  will  be  system  users  that  disagree  with  the  way  the  ERP 
template  matches  the  traditional  business  processes  of  the  organization.  The 
disagreement  will  occur  when  the  template  does  not  include  a  process  or  capability  that  a 
power  user  or  business  baron  believes  should  be  in  the  ERP.  If  the  power  organizational 
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player  wins  the  day  and  the  ERP  is  changed,  then  the  number  one  pitfall  (customization) 
is  realized  and  the  organization  is  in  trouble.  This  is  the  principal  source  of  ERP  pain 
because  it  makes  the  system  unstable  and  hard  to  maintain.  It  negates  the  benefit  of 
having  a  proven  template  and  it  is  the  most  commonly  cited  reason  for  ERP  problems 

[17]. 

Every  organization  is  different  and  a  measure  of  customization  is  needed  by  all. 
The  important  thing  is  the  customization  must  be  kept  to  a  minimum.  Capabilities  in  the 
legacy  software  may  not  be  in  the  ERP.  There  is  going  to  be  lost  capability  in  every  ERP 
project.  On  the  other  hand,  to  obtain  the  enterprise  wide  integration  that  the  ERP  is 
attempting  to  achieve,  a  measure  of  sacrifice  is  going  to  be  required  in  the  hope  that  the 
benefit  more  than  justifies  the  sacrifice.  Thus,  a  close  examination  should  be  made  to 
determine  if  the  capability  is  a  necessity  or  not.  If  it  is  not  a  necessity  it  can  be  discarded 
in  the  interest  of  the  organization  as  a  whole.  Conversely,  if  the  “strong  man”  of  the  ERP 
project  team  concludes  that  it  is  a  necessity,  an  interface  to  the  capability  is  a  better 
choice  than  modifying  the  core  ERP  software.  To  cover  the  gaps  between  the  necessary 
processes  and  capabilities  and  the  embedded  processes  in  the  ERP,  the  acronym  RICE  is 
used.  RICE  stands  for  reports,  interfaces,  conversions,  enhancements.  It  is  the  order  that 
solutions  should  be  sought  to  cover  the  gaps.  The  first  possibility  to  be  explored  is  a 
report.  If  the  same  information  that  is  in  the  legacy  system  can  be  retrieved  using  a  report 
out  of  the  ERP,  then  that  is  the  best  solution.  Secondly,  an  interface  to  a  system  that  has 
the  required  capability  is  the  next  best  solution.  If  that  does  not  work  than  a  conversion 
of  the  data  in  the  old  system  into  a  form  that  the  logic  in  the  ERP  can  handle  is  the  third 
option.  Finally,  if  nothing  else  can  be  done,  enhancing  the  core  ERP  can  take  place.  It  is 
imperative  that  this  option  should  only  be  selected  as  a  last  resort  when  there  is  no 
possible  alternative  to  achieving  the  capability  [39], 

In  order  to  make  determinations  about  the  necessity  of  processes  and  capabilities, 
the  “strong  man”  has  to  be  someone  at  the  highest  levels  of  an  organization.  If  it  is  a 
person  that  does  not  have  the  required  power  to  make  and  enforce  all  the  decisions 
concerning  the  ERP,  then  the  organizational  barons  will  win  and  the  result  will  be  an 
extraordinarily  expensive  piece  of  custom  software  that  is  unstable  and  can  potentially 
bring  the  organization  to  a  standstill  [17]. 
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G.  LIFE  CYCLE 

Helping  organizations  avoid  the  pitfalls  navigate  through  an  implementation  is  the 
ERP  life  cycle. 


ERP  LIFE  CYCLE  CHART 


Product  Evaluation 

Project  Management  &  Consulting 

Training 

JDEtips  Journal 


|  Complementary  Software 
|  Maintenance  &  HelpDesk 
|  Permanent  Placement 
Sarbanes-Oxley  Compliance 


Implementation 
P haae  I  — 

Select  Consulting  Partner, 
Implement  Financials 
(possibly  do  a  Big  Bang, 
which  would  encompass 
parts  of  the  next  phase), 
Conduct  go-live  readiness 
assessments. 


Declining  Value  — 

Value  declines  as  the  ERP  solution  ages,  and 
new  business  requirements  and  technologies 
emerge.  Upgrading  is  now  nearly  as  costly  as 
implementing  a  new  ERP  solution.  This  phase 
leads  to  the  next  Product  Evaluation  phase. 


Product  Evaluation  — 
Prepare  RFP,  Evaluate  ERP 
Solutions,  Sign  Contract. 


Maintaining  Value  — 

Few  changes,  but  an  emphasis  on 
getting  more  value  from  the  ERP 
investment.  Typical  activities  include 
a  fresh  look  at  business  processes, 
and  continuing  to  customize  the 
solution  whore  COSt  justified. 


Extending  Value  — 

Upgrade  to  current  ERP  release  and 
add  complementary  functions  such 
as  EDI,  Advanced  Planning,  CRM, 
SRM,  and  Business  Intelligence. 


Implementation  Phase  II 
and  Beyond  - 
Re-evaluate  Consulting  Partner, 
and  continue  implementing  Core 
ERP  functionality,  such  as; 
Logistics/Manufacturing/ 
HR  A  Payroll, 


Figure  2.6.  ERP  Life  Cycle  (From:  [40]) 
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1. 


Product  Evaluation 


After  making  the  decision  to  look  at  ERP  software,  the  first  phase  of  the  life  cycle 
is  product  evaluation.  During  the  product  evaluation  stage,  the  vision  for  what  the 
organization  wants  the  system  to  do  needs  to  be  established.  Before  any  vendors  are 
brought  in  to  demonstrate  the  capabilities  of  their  systems,  the  organization  has  to  ask 
itself:  what  are  the  requirements  of  the  system  that  we  plan  to  select?  What  does  it 
absolutely  have  to  do  in  order  for  us  to  conduct  business?  Where  are  the  areas  we  are 
looking  to  improve?  Once  these  requirements  are  outlined,  a  request  for  proposal  should 
be  issued  to  some  prospective  vendors  asking  them  how  they  handle  the  key 
requirements.  It  is  beneficial  to  have  the  vendors  submit  screen  shots  with  their 
proposals  for  the  handling  of  requirements  since  a  picture  is  worth  a  thousand  words  [40], 

The  vendors  with  the  top  three  proposals  should  be  invited  for  a  demonstration 
day.  All  of  the  operational  leaders  of  the  organization  and  head  IT  personnel  who  will  be 
involved  in  the  project  ought  to  be  present  for  the  demonstration  to  discuss  functionality 
and  technology.  The  leaders  will  also  want  to  use  the  demonstration  time  to  dissect  how 
the  corporate  culture  of  the  vendor  matches  that  of  the  buying  organization.  They  can  do 
this  with  questions  like  [40]: 

•  Is  this  vendor  someone  you  want  to  do  business  with? 

•  Will  they  be  responsive  when  you’ve  got  a  dead-in-the -water  situation? 

•  Does  the  vendor  have  a  culture  that  wants  to  do  a  fantastic  job  of  taking 
care  of  their  customers? 

•  Can  they  give  examples  of  where  they  have  done  that  before? 

With  the  last  question,  it  is  especially  important  to  listen  for  an  answer  where  the  vendor 
has  done  a  fantastic  job  for  an  organization  that  is  functionally  similar  to  the  buying 
activity.  The  demonstration  and  the  questions  that  follow  will  provide  enough  insight  to 
pick  an  appropriate  ERP  system. 

2.  Implementation  Phase  I  and  II 

Implementation  is  generally  not  done  by  the  vendor.  Usually,  an  integrator  is 
selected  to  assist  the  transitioning  organization  with  the  implementation.  Integrators  are 
consulting  firms  that  are  helpful  when  there  is  not  a  large  body  of  “in-house”  expertise  on 
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enterprise  systems  [41].  The  leading  integrators  in  the  ERP  market  are  the  large  IT 
consulting  firms  such  as  Accenture,  Bearing  Point,  Computer  Sciences  Corporations 
(CSC),  Price  Waterhouse  Coopers,  EDS,  and  IBM  [2],  Selecting  the  right  integrators  is 
critical  because  they  are  the  link  between  the  organization’s  needs  and  the  ERP  chosen. 
Additionally,  the  integrator  is  going  to  structure  the  plan  for  the  implementation  so  their 
reputation  in  ERP  undertakings  at  a  scale  that  is  equivalent  to  the  one  being  asked  for  is 
extremely  important  [41]. 

The  integrator  will  guide  an  organization  along  what  is  known  as  the  proven  path. 
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Figure  2.7.  ERP  Proven  Path  (After:  [8]) 

Developed  by  Daryl  Landvater  in  the  mid-1970s,  the  Proven  Path  is  a  set  of  well-defined 
steps  that  an  organization  should  take  to  successfully  complete  implementation  phase  I 
and  II  of  the  ERP  life  cycle.  It  is  a  methodology  that  is  followed  by  integrators  and  has 
been  proven  to  work  because  it  properly  aligns  with  the  priorities  of  an  ERP.  The 
priorities  for  making  an  ERP  implementation  successful  are  people,  data,  and  computer. 
People  within  the  organization  are  the  first  priority  because  of  the  change  that  is  going  to 
take  place  with  an  ERP.  At  all  levels  of  the  organization  people  are  going  to  manage  the 
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implementation  and  either  back  it  or  stand  against  it.  Getting  positive  results  is  going  to 
hinge  on  getting  support  for  the  change.  Data  is  going  to  come  out  of  the  legacy  systems 
and  go  into  the  ERP  and  therefore  it  is  imperative  that  this  data  is  accurate  and  correctly 
structured.  If  it  is  not  then  a  “garbage-in,  garbage-out”  scenario  will  result.  The  last 
priority  of  ERP  is  the  computer  which  encompasses  both  hardware  and  software.  ERP  is 
a  software  initiative  and  it  must  be  installed  and  configured  correctly  for  it  to  work  as 
planned.  Set  to  a  19-month  implementation  timetable,  the  Proven  Path  adheres  to  an 
aggressive  schedule  because  the  attention  spans  of  both  organizations  and  people  are 
limited.  Any  one  project  can  only  hold  the  top  priority  in  an  organization  for  so  long. 
The  monumental  shift  to  an  ERP  requires  that  it  be  the  top  priority.  Since  it  is  unlikely 
that  is  can  hold  this  position  for  three  or  four  years,  the  best  tactic  is  to  implement  it 
quickly. 


a.  Project  Organization 

After  an  ERP  vendor  and  an  integrator  have  been  selected,  the  first  step  on 
the  Proven  Path  is  project  organization.  This  is  where  the  project  leader  and  his  staff  will 
be  selected  and  the  implementation  plan  will  be  developed. 

b.  Performance  Goals 

Along  with  establishing  the  plan,  the  project  team  will  also  come  to  an 
agreement  about  the  goals  of  the  project.  Specifically,  categories  of  the  business  that  are 
to  be  improved  will  be  delineated  and  the  levels  of  performance  those  categories  are  to 
reach  will  be  established. 

c.  Initial  Education  and  Training 

Given  that  people  are  the  first  priority  in  an  ERP,  educating  the  people  in 
the  organization  about  the  change  is  the  top  priority  in  the  Proven  Path.  The  goal  should 
be  to  educate  100%  of  the  people  affected  by  the  ERP.  At  a  minimum,  80%  of  those 
people  have  to  be  educated.  They  need  to  understand  why  the  organization  is  making  the 
transition,  what  the  benefits  are  and  what  will  be  expected  of  them.  If  people  are  going  to 
be  required  to  change  the  way  they  work,  the  benefit  to  doing  so  must  be  clearly 
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communicated.  Additionally,  the  powerful  entities  within  the  organization  should  be 
educated  on  the  pitfalls  of  an  ERP  so  they  can  help  the  organization  avoid  them. 

d.  Sales  &  Operations  Planning 

Once  education  is  underway,  the  sales  and  operations  planning  (S&OP) 
portion  the  ERP  can  begin  implementation.  This  is  first  behind  education  because  it 
involves  relatively  few  people  but  it  is  the  main  driver  behind  the  functioning  of  the 
organization.  The  sales  forecast  is  a  prediction  of  what  is  going  to  be  demanded  by 
customers.  From  this  prediction,  the  operations  plan  is  set  in  motion  to  produce  what  will 
be  demanded.  In  essence,  the  S&OP  encompasses  what  the  organization  does  and  in  an 
ERP  it  is  the  most  important  element.  Thus,  it  is  the  first  element  in  the  implementation 
phase. 


e.  Demand  Management,  Planning,  and  Scheduling  Processes 

Underneath  S&OP  is  demand  management,  planning,  and  scheduling. 
Whereas  S&OP  covers  what  is  going  to  be  required  at  the  highest  level,  demand 
management,  planning,  and  scheduling  is  the  detail  information  that  goes  into  the  top- 
level  forecast.  It  includes  the  mix  of  products  that  should  be  made  and  the  specific 
customers  that  are  going  to  receive  those  products.  Additionally,  the  new  approaches  to 
forecasting  demand  and  order  entry  are  covered  in  this  step.  The  processes  are  defined 
and  a  pilot  is  used  to  demonstrate  those  processes.  Once  the  pilot  is  proved  successful,  it 
will  be  implemented  and  a  new  customer  order  entry,  forecasting,  and  detailed  planning 
and  scheduling  processes  will  be  running. 

f.  Data  Integrity 

Checking  the  integrity  of  the  data  going  into  the  ERP  will  commence  at 
project  initiation  and  continue  throughout  much  of  the  implementation  schedule.  Due  to 
the  fact  that  ERP  requires  a  level  of  data  integrity  that  is  so  high,  this  step  can  not  be 
underestimated.  It  is  arduous  detail  oriented  work  but  if  it  is  not  done  properly,  the  ERP 
will  produce  the  wrong  information. 
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g.  Finance  and  Accounting  Processes 

Every  action  taken  by  an  organization  has  financial  implications.  In 
commercial  entities,  the  accounting  standards  that  must  be  adhered  to  are  well  understood 
and  codified  in  ERPs  so  this  step  takes  lower  on  the  scale  of  importance  in  the  Proven 
Path.  However,  for  a  public  organization,  the  financial  processes  that  are  to  be  followed 
are  not  as  transparent.  Either  way,  the  financial  processes  must  be  continually  defined  all 
the  way  through  implementation. 

3.  Extending  Value 

At  the  completion  of  the  proven  path,  the  organization  can  make  the  decision  to 
add  the  additional  features  that  have  come  on  the  market  to  enhance  their  ERP.  This  is 
the  step  where  the  particular  divisions  get  those  “nice  to  have”  items  that  are  not  part  of 
standard  ERP.  Items  such  as  Customer  Relationship  Management  (CRM),  Supplier 
Relationship  Management  (SRM),  and  Business  Intelligence  software  are  costly  additions 
to  the  functionality  of  the  core  ERP  [40].  The  extensions  selected  should  align  with  the 
strategic  goals  of  the  organization.  Integration  of  the  ERP  with  a  higher  level  of  the 
corporation  or  public  entity  also  takes  place  during  the  extending  value  phase  of  the  life 
cycle. 

4.  Maintaining  Value 

Five  to  seven  years  after  the  beginning  of  the  ERP  project,  the  maintenance  phase 
of  the  life  cycle  is  entered.  During  the  maintenance  phase,  the  aim  is  to  get  as  much  life 
out  of  the  ERP  as  possible.  An  additional  five  to  ten  years  is  ideal.  Small  improvements 
will  be  made  as  business  needs  change  but  no  major  modifications  take  place  [40]. 

5.  Declining  Value 

At  some  point  the  business  changes  have  outgrown  the  existing  ERP. 
Technological  advances  have  changed  the  landscape  and  now  the  organization  must 
change  again  to  remain  competitive.  Approximately  twenty  years  after  starting  the  ERP 
project,  in  the  declining  value  phase  it  is  time  to  begin  preparations  to  start  the  ERP  life 
cycle  again  [40], 
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III.  ERP  IN  THE  DOD 


A.  BACKGROUND 

The  supply  chain  problems  of  the  first  Gulf  War,  the  ERP  success  stories  of  the 
private  sector  and  the  legislation  passed  during  the  early  to  mid  1990s  steered  the  DOD 
toward  ERP  as  a  viable  means  of  correcting  the  deficiencies  of  the  Department’s  Cold 
War  era  business  systems.  In  1997,  two  internal  DOD  documents  were  published  that 
emphasized  that  the  time  had  come  to  transform  the  Department’s  business  environment 
and  systems. 

1.  The  1997  Quadrennial  Defense  Review 

The  first  document  to  outline  the  path  toward  transformation  was  the  1997 
Quadrennial  Defense  Review  (QDR).  In  the  QDR,  the  senior  DOD  leadership  outlined 
the  current  state  of  the  Armed  Forces  and  defined  the  direction  the  Department  needed  to 
go  to  face  current  and  future  global  threats  to  U.S.  security.  The  1997  QDR  focused  on 
this  purpose  but  it  also  contained  a  description  of  the  plan  to  implement  “focused 
logistics”  [42], 
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Figure  3.1.  Full  Spectrum  Dominance  (From:  [43]) 
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First  defined  in  the  DOD’s  Joint  Vision  2010,  “focused  logistics”  is  one  of  the 
four  pillars  of  “full  spectrum  dominance”.  As  a  military  concept,  “full  spectrum 
dominance”  implies  a  capability  to  control  all  elements  of  the  physical  battlespace, 
electromagnetic  spectrum  and  information  space  using  a  combination  of  land,  air, 
maritime  and  space  based  assets.  By  controlling  these  elements,  the  U.S.  would  be  able 
to  prevent  the  opposing  force  from  operating  in  these  realms  [43].  The  “focused 
logistics”  portion  of  the  operating  concept  envisioned  the  services  and  civilian  defense 
organizations  working  jointly  to  provide  the  operating  forces  precisely  the  supplies  they 
need  when  they  need  them. 


Figure  3.2.  Focused  Logistics  (From:  [43]) 

To  achieve  “focused  logistics,”  the  DOD  planned  to  leverage  the  supply  chain 
information  systems  and  business  processes  of  the  civilian  sector.  In  the  1990s,  the 
commercial  sector  was  continually  getting  “leaner”  by  carrying  smaller  inventories  and 
using  IT  to  deliver  products  to  customers  at  the  exact  time  needed.  For  many  of  the 
commercial  companies  capable  of  the  supply  chain  practices  sought  by  “focused 
logistics”,  The  IT  enabler  of  the  advanced  supply  chain  business  practices  was  an  ERP. 

Placing  “focused  logistics”  as  one  of  the  four  pillars  of  Joint  Vision  2010 
demonstrated  that  the  DOD  intended  to  make  a  significant  investment  in  improving  the 
way  it  performed  supply  chain  management.  After  being  revealed  in  Joint  Vision  2010, 
the  plan  to  invest  heavily  in  developing  state-of-the-art  logistic  practices  and  doctrine  was 
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confirmed  in  the  1997  QDR.  The  QDR  stated  that  “focused  logistics  will  reduce  the 
overall  size  of  logistics  support  while  helping  to  provide  more  agile,  leaner  combat  forces 
that  can  be  rapidly  deployed  and  sustained  around  the  globe”  [42],  This  statement  clearly 
demonstrated  the  shift  from  the  mass  inventory  methodology  of  the  first  Gulf  War.  In  the 
late  1990’s,  the  DOD  planned  to  put  money  into  ERP  systems  capable  of  providing  more 
responsive  logistics  support. 

2.  The  1997  Defense  Reform  Initiative 

After  the  release  of  the  QDR,  the  second  document  published  in  1997  to  outline 
the  course  toward  transformation  was  the  1997  Defense  Reform  Initiative  (DRI). 
Chartered  by  the  Secretary  of  Defense  William  Cohen,  the  purpose  of  DRI  was  to  study 
changes  that  must  be  made  to  the  DOD  business  systems  to  better  meet  the  requirements 
of  the  operating  forces.  The  concluding  report  of  the  study  authorized  the  services  and 
DOD  support  agencies  to  begin  IT  projects  to  acquire  systems  that  will  help  the 
Department  perform  “just-in-time”  logistics.  Logistics  where  critical  supplies  and  spare 
parts  are  not  stockpiled  just-in-case  they  are  needed  but  rather  are  delivered  when  needed. 
The  report  states,  “Just-in-time  logistics  is  revolutionizing  the  private  sector  and  can  do 
the  same  for  the  DOD”  [44],  To  execute  “just-in-time”  logistics,  the  service  components 
and  DOD  logistics  components  needed  to  abandon  the  paperbound  logistics  systems  of 
the  past  and  embrace  the  IT  systems  of  the  private  sector. 

B.  DEPARTMENT  OF  THE  NAVY 

Given  the  high  level  guidance  of  the  1997  QDR  and  DRI,  the  Department  of  the 
Navy  (DON)  began  to  look  for  the  best  way  to  achieve  the  state-of-the-art  logistics 
capability  called  for  in  Joint  Vision  2010.  Additionally,  the  Navy  wanted  systems  that 
could  lead  to  compliance  with  the  Federal  Financial  Management  Improvement  Act  of 
1996.  In  order  to  meet  the  requirements  of  the  FFMIA,  the  systems  would  have  to  “... 
comply  substantially  with  (1)  federal  financial  management  systems  requirements,  (2) 
applicable  federal  accounting  standards,  and  (3)  the  U.S.  Government  Standard  General 
Ledger  (SGL)  at  the  transactions  level”  [1],  Essentially,  what  the  Navy  was  looking  for 
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was  systems  that  would  make  the  supply  chain  processes  more  agile  and  responsive  and 
provide  accountability  of  funds  to  American  taxpayers. 

1.  Revolution  in  Business  Affairs 

To  achieve  this  objective,  the  first  thing  the  Navy  did  was  establish  an  executive 
committee  in  December  1997  that  was  held  responsible  for  looking  for  ways  to  transform 
DON  business  affairs  and  systems.  The  committee  was  dedicated  to  what  the  Navy 
called  a  “Revolution  in  Business  Affairs  (RBA)”  [2],  A  revolution  where  the  Navy 
planned  to  change  the  way  it  traditionally  did  business  in  favor  of  more  modem 
approaches. 

2.  Commercial  Business  Practices  Working  Group 

A  goal  of  the  committee  for  the  RBA  was  to  investigate  the  systems  that  were 
being  used  in  the  commercial  sector  that  provided  the  information  backbone  of  the 
modem  business  approaches.  The  RBA  committee  did  this  by  forming  a  separate  sub¬ 
committee  named  the  Commercial  Business  Practices  (CPB)  Working  Group.  Made  up 
of  personnel  taken  from  financial  management  organizations  throughout  the  DON,  the 
CPB  working  group  recommended  that  ERP  systems  should  be  used  to  drive  the  change 
that  was  sought  [45].  Based  upon  that  recommendation,  six  ERP  pilot  programs  were 
authorized  but  due  to  a  lack  of  funding,  only  four  pilot  programs  proceeded.  The  four 
pilot  programs  that  received  funding  included  [2]: 

•  SMART-  Aviation  Supply  &  Maintenance:  maintenance  planning  and 
supply  support  processes  sponsored  by  the  Naval  Air  Systems  Command 
(NAVAIRSYSCOM)  and  the  Naval  Supply  Systems  Command 
(NAVSUPSYSCOM). 

•  SIGMA-  Acquisition  Program  Management:  program  management 
processes  to  include  linkage  between  contracting  and  financial  systems 
sponsored  by  the  Naval  Air  Systems  Command  (NAVAIRSYSCOM). 

•  CABRILLO-  Navy  Working  Capital  Fund  (NWCF)  Financial 
Management:  management  of  the  Navy  Working  Capital  Fund  within 
acquisition  commands  sponsored  by  Space  and  the  Naval  Warfare 
Systems  Support  Center  San  Diego  (SSC-SD). 

•  NEMAIS-  Regional  Maintenance:  avionics  and  repair  center  processes 
across  surface,  air,  and  subsurface  communities  sponsored  by  the 
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Commander  in  Chief  Atlantic  Fleet  (CINCLANTFLT)  and  the  Naval  Sea 
Systems  Command  (NAVSEASYSCOM). 

3.  Commercial  Business  Practices  Executive  Steering  Group 

At  the  beginning  of  the  projects  in  December  1998,  the  Navy  established  a  (CBP) 
executive  steering  group  to  monitor  the  activities  of  the  pilot  projects.  The  executive 
steering  group  monitored  the  projects  but  did  not  manage  the  projects.  Since  the  projects 
were  individually  funded  by  the  sponsoring  commands,  they  were  individually  managed 
by  the  sponsoring  commands.  Furthermore,  the  separate  sponsors  had  different  business 
concerns  based  upon  the  particular  business  function  of  the  supporting  activity  [45],  For 
example,  SSC-SD  is  a  Working  Capital  Funded  (WCF)  organization  and  because  of  this 
role,  it  was  assigned  responsibility  for  judging  ERP’s  ability  to  manage  government 
financial  management.  Specifically,  SSC-SD  was  to  judge  the  following  areas  [2]: 

•  Financial  management-  All  financial  activities  including  budgets,  funds 
management,  billings,  payables,  reporting,  and  employee  data. 

•  Procurement  management-  All  buying  activities  for  maintenance,  repair, 
and  overhaul  items,  from  issuing  a  purchase  order,  receipt  of  goods,  and 
processing  vendor  invoices. 

•  Asset  management-  Including  both  real  property  and  improvements. 
Tracking  all  assets  from  acquisition  to  disposal. 

•  Project  management-  Fully  integrated  project  management  systems  that  tie 
together  project  management  tools  with  finance,  budgeting,  procurement, 
and  asset  management  data. 

•  Strategic  management-  Planning  and  budgeting  tool  for  both  annual  and 
long  range  planning.  It  will  build  upon  annual  budgeting  and  planning 
needs  to  develop  a  long-range  orientation  for  SSC-SD. 

4.  ERP  and  Integrator  Selection 

The  plan  followed  by  the  project  teams  at  the  separate  sponsoring  commands 
adhered  to  the  steps  of  the  ERP  life  cycle.  A  business  case  analysis  (BCA)  was 
conducted  at  each  of  the  commands  to  outline  the  vision  of  what  the  organizations  were 
attempting  to  achieve  with  their  ERPs.  The  BCAs  accomplished  this  task  by  outlining 
the  “As  Is”  business  processes  of  the  commands  and  then  compared  those  processes  to 
the  business  processes  of  an  ERP.  A  side  by  side  comparison  revealed  the  differences  in 
the  way  the  work  would  be  performed  with  an  ERP  and  highlighted  the  areas  where 
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processes  would  be  reengineered  and  improved  by  the  ERP.  The  reengineered  business 
processes  of  the  ERP  were  labeled  the  “To  Be”  business  models  [2], 

Once  the  vision  of  what  the  sponsoring  activities  wanted  to  achieve  was  outlined 
in  the  “To  Be”  business  models,  it  was  time  to  select  an  ERP  vendor  that  best  fit  the 
model.  All  of  the  pilot  programs  selected  SAP’s  R/3  (Release  3)  software  for  their 
projects. 
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Figure  3.3.  SAP  R/3  Architecture  (From:  [2]) 


The  R/3  architecture  was  chosen  because  the  different  business  areas  of  the  system  are 
divided  into  modules  which  allow  for  certain  function  points  to  be  implemented  while 
others  can  be  excluded  or  left  for  implementation  at  a  later  time.  This  provides  the  user 
with  the  flexibility  to  implement  in  stages  thereby  reducing  the  risk  associated  with 
implementing  a  system  in  a  single  release.  Additionally,  at  the  time  of  the  decision  in  the 
late  1990s,  the  R/3  software  was  the  preeminent  software  selected  by  the  U.S. 
Government  customers.  It  was  the  ERP  software  of  the  U.S.  Mint,  the  Strategic 
Petroleum  Reserve  and  most  importantly,  it  was  the  ERP  software  the  U.S.  Army  planned 
to  use  for  the  Logistics  Modernization  Program  [LMP]  that  was  underway  at  the  same 
time  as  the  Navy  pilots  [3].  This  is  important  because  the  overall  goal  of  Joint  Vision 
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2010  was  joint  operations  to  include  joint  logistics.  Thus,  if  the  systems  were  to  be  tied 
together  at  some  point  in  the  future,  it  would  be  beneficial  if  they  were  all  using  the  same 
platform. 

Once  the  product  evaluation  phase  has  come  to  an  end,  the  next  step  in  the  ERP 
life  cycle  (implementation  phase  I)  involves  the  selection  of  a  consulting  partner 
(integrator).  A  big  decision  because  the  ultimate  goal  is  to  have  a  long  term  partnering 
relationship  that  has  to  thrive  to  keep  the  ERP  project  progressing.  If  the  relationship 
turns  hostile  and  the  integrator  can  no  longer  be  considered  a  trusted  advisor,  then  an 
integrator  change  has  to  take  place.  When  an  integrator  switch  occurs,  dramatic  setbacks 
are  the  result  because  it  takes  time  for  the  new  integrator  to  get  acquainted  with  the 
history  of  the  project  [46].  Each  of  the  four  separate  Navy  ERP  pilots  selected  different 
vendors  as  integration  partners  for  their  projects.  For  the  SMART  pilot,  the  program 
management  team  opted  to  work  the  Electronic  Data  Systems  Corporation  (EDS)  while 
SIGMA  teamed  with  Bearing  Point.  SSC-SD  selected  Price  Waterhouse  Coopers  for  the 
CABRILLO  project  and  IBM  was  chosen  as  the  integrator  for  the  NEMAIS  pilot. 

5.  Pilot  Results  and  Road  Ahead 

Between  late  1998  and  early  2002,  the  four  Navy  pilots  took  different  routes  with 
their  integrators  exploring  the  application  of  ERP  to  their  business  areas.  During  the 
course  of  the  projects,  issues  surfaced  that  required  the  attention  of  Navy  personnel 
higher  than  the  heads  of  the  Systems  Commands  sponsoring  the  individual  pilots.  The 
main  issue  that  needed  attention:  what  should  be  done  to  integrate  the  pilots  after  they 
had  achieved  their  independent  objectives?  This  led  the  Assistant  Secretary  of  the  Navy 
for  Research,  Development,  and  Acquisition  (ASN  RDA)  to  establish  a  single  ERP 
program  in  August  2002.  The  goal  of  the  program  was  the  convergence  and  replace  of 
the  four  pilots  by  fiscal  year  2008  [45], 

When  the  decision  was  made  to  proceed  with  a  single  Navy  ERP  program,  a 
central  program  office  was  founded  to  manage  the  converged  ERP.  In  the  beginning  of 
this  convergence  process,  the  program  office  undertook  extensive  software  architectural 
planning  due  to  the  fact  that  the  project  team  was  tasked  with  merging  established  ERP 
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solutions.  A  task  that  is  much  harder  than  starting  an  original  ERP  project  because  of  the 
care  that  must  be  taken  to  maximize  use  of  the  existing  SAP  instances  thereby 
minimizing  re-work. 

To  make  a  single  ERP  solution  out  of  the  four  pilots  a  reality,  the  designers  of  the 
architecture  have  approached  the  project  from  the  perspective  that  it  is  like  going  live 
with  an  ERP  in  two  divisions  of  a  large  company  and  then  merging  the  divisions  into  a 
single  system.  This  is  typical  of  the  work  that  has  to  be  done  following  the  acquisition 
and  mergers  of  separate  companies.  However,  before  convergence  of  the  systems  can 
begin,  a  vision  of  the  capability  that  the  converged  solution  is  supposed  to  deliver  must 
be  established  as  a  target  for  what  the  project  team  is  trying  to  achieve. 


Navy  Converged  Solution 

(Integrated  Value  Chain  is  the  Targeted  End  State) 


Integrated  Single  End-to-End  Navy  Solution  Adding  Value  to  the  Fleet! 


Figure  3.4.  Navy  Vision  for  a  Converged  Solution  (From:  [47]) 

For  the  Navy,  the  vision  of  the  converged  solution  aligns  with  the  Product  Lifecycle 
Management  (PLM)  approach  that  is  used  in  industry  to  manage  products  from 
acquisition  to  disposal.  In  this  case,  the  products  to  be  managed  are  the  major  end  items 


44 


that  are  procured  to  support  the  Navy’s  mission.  The  person  responsible  for  PLM  in  the 
commercial  sector  is  the  product  manager.  A  position  that  is  mirrored  in  the  DOD  by  the 
program  manager  who  “...  is  responsible  for  managing  the  complete  weapon  system  life 
cycle,  which  includes  concept  development,  R&D,  acquisition,  testing,  initial  fielding, 
sustainment  (including  maintenance),  in-service  support,  and  disposal”  [47], 

In  their  effort  to  achieve  the  end-state  of  a  single  ERP  that  manages  major  end 
items  from  “cradle  to  grave”,  the  Navy  has  to  overcome  the  fact  it  has  two  separate  SAP 
instances  (SIGMA  and  SMART)  managing  aviation  assets  and  another  SAP  instance 
(NEMAIS)  managing  maritime  assets.  The  plan  developed  to  handle  this  situation  in  the 
most  cost  effective  and  risk-minimizing  manner  calls  for  the  merger  of  the  two  aviation 
projects  (SIGMA  and  SMART)  into  a  single  instance  while  NEMAIS  will  be  expanded 
to  manage  all  maritime  assets.  Integration  between  the  systems  will  occur  because  SAP 
was  designed  to  control  business  functions  that  flow  across  organizational  divisions 
which  in  this  case  is  the  Navy  Systems  Commands  (SYSCOMS).  It  does  this  by 
artificially  dividing  the  software  to  allow  for  organizational  boundaries  while  business 
processes  between  the  divisions  flow  uninhibited  across  the  organizational  boundaries.  A 
graphic  of  the  arrangement  that  is  envisioned  is  depicted  below. 


The 


Current 


Situa  tion 


Software  is  "Artificially  Divided"  to  Align 
with  Existing  Organizational  Boundaries 


Figure  3.5.  Current  Navy  Situation  (From:  [47]) 
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The  end-state  that  the  Navy  is  currently  working  towards  is  an  operational 
architecture  with  two  value  chains  (aviation  and  maritime)  that  manage  the  life  cycle  of 
weapons  systems  from  beginning  to  end.  Both  value  chains  will  be  include  concept 
development,  budgeting,  acquisition,  testing  and  evaluation,  maintenance,  in-service 
support,  and  disposal  as  well  as  all  the  supporting  business  processes  associated  with 
these  activities.  Essentially,  the  two  value  chains  will  conduct  the  same  business 
processes  outlined  in  Figure  3.4  with  a  different  look  and  feel  to  maximize  the  use  of  the 
work  that  was  conducted  on  the  separate  pilot  projects.  The  CABRILLO  project  of  SSC- 
SD  will  remain  separate  from  the  envisioned  architecture  because  as  a  Working  Capital 
Fund  organization,  the  financial  process  of  SSC-SD  does  not  match  the  financial  process 
of  the  other  SYSCOMS.  Therefore,  CABRIFFO  will  operate  as  a  stand-alone  financial 
stovepipe  system  [47], 

C.  DEPARTMENT  OF  THE  ARMY 

Fike  the  Navy,  the  U.S.  Army  immediately  went  to  work  on  focused  logistics 
following  the  release  of  the  QDR  and  DRI.  In  August  1997,  the  Deputy  Commanding 
General  of  the  Army  Material  Command  (AMC)  issued  a  memorandum  to  the 
Communications-Electronics  Command  (CECOM)  that  asked  the  command  to  [3]: 

a.  Determine  feasible  alternatives  for  logistics  modernization  strategies, 

b.  consider  the  implications  and  devise  methods  to  soften  the  impact  on  the 
existing  workforce, 

c.  develop  a  performance-based  statement  of  requirements,  and 

d.  to  recommend  an  acquisition  approach. 

Specifically,  the  Commanding  General  wanted  the  CECOM  to  form  a  project  team  tasked 
with  conducting  market  research  to  explore  the  IT  systems  being  used  by  the  commercial 
sector.  The  overall  vision  the  General  was  working  toward  was  an  AMC  that  integrated 
the  best  practices  and  technologies  of  the  private  sector  to  transform  the  Army’s 
wholesale  logistics  automation  systems. 
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1. 


The  CCSS  and  the  SDS 


Written  in  Common  Business  Oriented  Language  (COBOL),  the  Commodity 
Command  Standard  System  (CCSS)  and  the  Standard  Depot  System  (SDS)  are  the 
wholesale  logistics  automation  systems  the  General  was  referring  to.  The  purpose  of 
these  systems  was  to  support  the  Army’s  annual  procurement  of  supplies  and  equipment 
from  commercial  vendors,  the  General  Services  Administration  (GSA)  and  Defense 
Logistics  Agency  (DLA).  A  big  problem  with  the  systems  is  that  as  of  August,  1997,  the 
technology  being  used  was  thirty  years  old.  The  systems  were  being  maintained  by 
CECOM  funded  federal  IT  employees  who  worked  at  two  central  design  activity  (CD A) 
logistics  centers  in  St.  Louis,  Missouri,  and  Chambersburg,  Pennsylvania.  It  was  these 
programmers  that  the  General  wanted  to  “. .  .soften  the  impact  on. . .”  if  it  was  decided  that 
it  was  in  the  best  interest  of  the  AMC  to  adopt  commercially  available  IT  systems. 

The  problem  with  the  CCSS  and  the  SDS  had  more  to  do  with  their  inflexibility 
and  unresponsiveness  than  their  age.  In  their  analysis,  the  project  team  at  CECOM 
tasked  with  planning  the  approach  the  Army  should  take  with  their  business  system 
transformation  concluded  that  the  weaknesses  of  the  CCSS  and  SDS  systems  are  [48]: 

•  Lack  of  flexibility.  Process  changes,  regulatory  changes,  and 
reorganizations  within  and  between  user  commands  require  expensive  and 
extensive  data  conversions  and  programming  changes. 

•  Slow,  unfocused  reports :  Reporting  and  summarization  capabilities  are 
geared  to  workers.  Managers  and  executives,  with  their  need  for  easily 
specified,  flexible,  tailored,  and  rapid  generation  of  reports  and  summaries 
are  usually  frustrated  with  output  capabilities. 

•  Difficult  to  use :  The  system  is  not  user  friendly.  The  system  relies  on 
extensive  use  of  codes  to  provide  compact  storage  (a  holdover  from  the 
time  when  computer  storage  was  inordinately  expensive).  Users  are 
required  to  learn  codes  and  have  extensive  system  knowledge.  The  system 
lacks  adequate  data  edits  and  validations,  as  well  as  support  functions. 

•  Expensive  to  maintain :  The  system’s  size  and  complexities  make  it 
difficult  to  manage  and  change  code.  Large  portions  are  based  on 
relatively  old  third-generation  programming  languages  and  flat  data 
structures  that  are  inflexible  to  change  and  inefficient  to  operate. 

•  Unresponsive :  The  use  of  batch  processing  precludes  timely  updates  to 
data  architecture,  flexible  data  retrieval  capabilities,  and  informed 
decision-making. 


47 


•  Outmoded  database :  The  use  of  outmoded  database  systems  and 
architecture  result  in  rampant  data  inconsistencies,  data  duplication,  and 
the  lack  of  data  standardization. 

•  Expensive  to  operate :  The  system  requires  extensive  manual  intervention 
because  of  outmoded  data  and  system  architectures. 

•  Lack  of  cost-sharing :  The  Army  is  the  only  “bill  payer,”  precluding  the 
ability  to  leverage  existing  industry  investments  in  modem  logistics 
processes  and  IT. 

After  identifying  the  problems  with  the  legacy  systems,  the  project  team  had  to  come-up 
with  a  solution  using  the  $426  million  operating  budget  that  was  set  aside  for  operations 
and  maintenance  of  the  existing  systems  for  the  period  between  1997  and  2007.  As  was 
done  with  the  Navy  pilot  projects,  the  Army  planned  to  use  the  operating  funds  of  the 
sponsoring  command  to  fund  the  transformation  effort.  In  the  Army’s  case,  the 
sponsoring  command  was  the  AMC. 

3.  The  Army’s  Plan  to  Modernize 

Three  alternatives  were  devised  by  the  CECOM  project  team  to  achieve  the 
reengineered  logistic  processes  and  modernized  systems.  The  first  alternative  was  ruled 
out  because  it  did  not  meet  the  cost  constraint  and  the  schedule  was  deemed  too  lengthy. 
Alternative  two  was  a  financially  viable  option  but  there  was  no  “soft-landing”  for  the 
478  federal  programmers  at  the  two  CDAs.  Consequently,  it  was  feared  that  a  hostile 
relationship  would  develop  between  the  contractor  personnel  and  the  CDA  employees.  A 
situation  that  would  likely  result  in  government  employees  sabotaging  the  program.  The 
last  alternative  was  the  only  option  that  met  the  mandate  of  a  “soft-landing”  for  the  CDA 
programmers  and  fell  within  the  budgetary  guidelines. 
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INVESTMENT/IMPLEMENTATION 


*  INVESTMENT  C  OST  TO  GOVERNMENT  THROl’GH  DEPLOYMENT 


Figure  3.6.  Investment/Implementation  Comparison  (From:  [3]) 

In  the  seven  year  period  between  fiscal  years  1999  and  2005,  the  modernization  project 
would  cost  $253.5  million.  The  ten  year  cost  of  the  project  (1999  to  2009)  was  projected 
to  be  $420.9  million.  A  savings  of  $4.3  million  would  be  realized  and  the  federal 
programmers  would  receive  their  “soft-landing”  because  “Under  alternative  three,  the 
soft-landing  was  an  arrangement  in  which  the  winning  contractor  would  agree  to  employ 
the  government  employees  affected  by  the  transition  for  a  pre-specified  period  of  time, 
offering  competitive  pay  and  benefits”  [3],  Alternative  3  had  the  lowest  price  tag 
because  the  winning  contractor  would  have  to  be  willing  to  operate  at  a  loss  during  the 
system  development  phase  (through  FY-2005)  while  the  new  system  is  being  built  and 
the  old  systems  are  still  being  maintained.  The  winning  contractor  would  recoup  their 
losses  over  the  life  of  the  contract  because  they  would  be  awarded  the  contract  for  the  full 
ten  years  and  receive  all  of  the  $420.9  million.  Losses  would  be  offset  in  the  later  years 
by  gains  that  would  be  realized  due  to  the  efficiencies  of  the  new  system. 

3.  Privatization 

Translating  the  plan  outlined  in  alternative  three  into  reality  required  privatization 
because  the  plan  called  for  the  movement  of  government  equipment  and  personnel  into 
the  private  sector  [49].  In  the  Spring  of  1998,  the  privatization  plan  encountered 
resistance  from  the  Office  of  the  Secretary  of  Defense  (OSD)  who  told  the  project  team 
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that  what  they  were  planning  was  an  outsourcing  initiative  and  thus,  the  team  would  have 
to  follow  the  guidelines  established  in  the  Office  of  Management  and  Budget  (OMB) 
Circular  A-76.  The  A-76  mandates  that  federal  employees  be  allowed  to  compete  against 
private  companies  for  a  contract  such  as  the  one  proposed.  A  downside  of  the 
competition  is  that  if  the  federal  employees  lose  the  competition,  they  also  lose  their  jobs 
[49].  The  project  team  did  not  want  such  a  competition  to  occur  because  they  knew  that 
the  CDA  employees  did  not  have  the  business  process  reengineering  and  IT  skills 
necessary  to  successfully  compete  for  the  contract.  If  they  lost  the  contract  and  lost  their 
jobs,  the  team  would  have  failed  to  provide  them  the  “soft-landing”  that  the  AMC 
Commanding  General  desired.  Therefore,  the  project  team  began  to  look  for  a  way 
around  the  requirements  of  the  A-76  and  found  what  they  were  looking  for  in  the  Circular 
itself.  The  Circular  contains  a  clause  which  allows  for  agencies  to  submit  an  application 
for  a  waiver  if  there  are  extenuating  circumstances.  Using  the  CECOM  attorneys,  the 
project  team  drafted  their  waiver  request  containing  the  justification  for  their  acquisition 
approach.  The  waiver  was  the  first  ever  submitted  and  was  approved  by  the  DOD  chain 
of  command  in  April  1999  [3], 

4.  The  Union  Battle 

Upon  notification  that  the  waiver  was  approved,  the  CDA  employees  began  to 
fight  in  order  to  stop  the  process.  Many  of  the  employees  did  not  want  to  transition  out 
of  the  federal  workforce  and  the  St.  Louis  workers  were  unionized  under  the  National 
Federation  of  Federal  Employees  (NFFE).  The  NFFE  filed  an  appeal  with  the  Army  in 
May  1999  and  got  the  attention  of  the  Congressional  representative  in  St.  Louis,  Dick 
Gephardt.  Though  not  under  a  union,  the  Chambersburg  CDA  employees  also  got  the 
attention  of  their  Congressional  representative  and  the  battle  to  keep  the  project  alive  got 
underway  in  Washington.  Using  the  logic  that  outsourcing  was  the  only  way  the  Army 
was  going  to  make  a  significant  transformation,  the  project  team  beat  out  the  resistance. 
In  addition  to  the  reason  in  the  argument,  the  fact  that  the  project  team  had  developed  a 
plan  to  take  care  of  the  Government  employees  helped  to  win  over  lawmakers  and  the 
DOD  leadership.  On  September  30,  1999,  the  Secretary  of  the  Army  rejected  the  NFFE 
appeal  and  the  project  moved  forward  [50].  Due  to  the  fact  that  the  Army  secretary  was 
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the  ultimate  authority  in  the  decision,  his  rejection  ended  the  fight.  Still,  when  the  time 
came  for  the  CDA  employees  to  accept  job  offers  from  the  winning  contractor,  only  205 
of  the  nearly  500  civil  service  employees  went  to  work  on  the  project.  The  others  opted 
for  early  retirements  or  transferred  to  a  different  federal  sector  [51]. 

5.  The  WLMP  Gets  Underway 

With  the  demise  of  the  CDA  employee  resistance  in  the  Fall  of  1999,  the  only 
thing  left  to  do  at  the  end  of  that  year  was  award  a  contract.  On  December  30,  1999,  the 
AMC  selected  the  Computer  Sciences  Corporation  (CSC)  as  the  integrator  for  the 
Wholesale  Logistics  Modernization  Program  (WLMP)  more  commonly  referred  to  as  the 
Logistics  Modernization  Program  (LMP)  [3].  The  task  assigned  to  CSC:  “...provide 
business  process  re-engineering  services  for  the  Army’s  current  wholesale  logistics 
processes  and  supporting  IT”  [52],  To  accomplish  this  task,  the  system  chosen  was  the 
same  system  selected  for  the  Navy’s  pilot’s,  SAP’s  R/3.  CSC  immediately  went  to  work 
on  the  LMP  and  by  November  2002  end-user  training  and  testing  was  underway  with  test 
designed  to  see  if  the  LMP  met  the  requirements  established  for  it  by  the  AMC  [53], 
Having  passed  the  initial  testing,  LMP  deployment  occurred  in  February  2003. 

6.  SALE 

While  the  LMP  project  team  was  handling  wholesale  logistics  support,  the  AMC 
got  started  working  on  the  retail  side  of  the  support  equation.  Retail  customers  are  the 
field-operating  commands  that  support  Army  units  in  combat.  They  are  the  units  that 
requisition  the  supplies  from  the  wholesale  level  that  is  holding  the  inventories  of  stocks. 
Both  the  retail  and  wholesale  projects  were  started  in  the  late  1990s.  However,  the 
programs  were  divided  because  the  plan  for  what  was  to  be  done  with  the  federal 
employees  responsible  for  development  and  maintenance  of  the  legacy  systems  was 
different.  As  was  discussed  previously,  the  wholesale  programmers  at  the  two  CDA  were 
to  be  retired,  transferred  or  handed  over  to  the  winning  contractor.  Unlike  the  legacy 
wholesale  environment  which  had  two  main  programs  (the  CCSS  and  SDS),  the  legacy 
retail  environment  contained  sixteen  separate  programs  with  thousands  of  federal 
employee  programmers.  This  problem  led  to  the  decision  that  the  federal  employees 
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should  continue  to  operate  the  legacy  systems  while  working  with  a  contractor  to  develop 
a  new  system  [51].  Work  on  the  new  system  began  in  1999  but  it  has  had  a  much 
lengthier  development  timeline  than  the  LMP  because  of  the  transitional  approach  taken. 
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Figure  3.7.  GCSS-Army  System  Migration  Diagram  (From:  Ref.  [54]) 

Titled  Global  Combat  Support  System-Army  (GCSS-Army),  the  retail  project  is 
still  in  the  early  stages  of  development  having  only  met  Milestone  B  of  the  Integrated 
Defense  Acquisition,  Technology,  &  Logistics  Lifecycle  Management  Framework  in 
March  of  2007.  The  vision  for  GCSS-Army  is  that  it  will  provide  the  Army  supply  clerk 
embedded  with  the  fighting  forces  a  single  application  for  tactical  logistics  at  home  and 
overseas.  It  will  achieve  this  end-state  by  slowly  transferring  the  capabilities  of  the 
multiple  systems  currently  in  use  into  a  single  system  running  on  an  SAP  R/3  framework. 
The  framework  currently  in  development  has  been  specially  designed  and  standardized 
with  other  Joint  and  NATO  partners  to  meet  the  requirements  of  the  modem  battlefield 
[55]. 

When  the  LMP  and  GCSS-Army  are  brought  together,  they  will  form  the  Single 
Army  Logistics  Enterprise. 
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What  is  Single  Army  Logistics  Enterprise  (SALE) 
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Figure  3.8.  What  is  Single  Army  Logistics  Enterprise  (SALE)  (From:  [55]) 

There  is  an  additional  entity  in  the  SALE  architecture  that  will  act  as  the  integrating  hub 
between  the  LMP  and  GCSS-Army.  Product  Lifecycle  Management  Plus  (PLM+)  is  a 
copy  of  what  was  seen  in  the  Navy’s  Converged  ERP  Solution  and  ties  the  whole  system 
together  by  structuring  the  data  so  that  every  aspect  of  the  life  cycle  of  a  weapon  system 
can  be  viewed  in  one  system.  Using  SAP’s  Master  Data  Management  (MDM) 
technology,  the  SALE  mandate  calls  for  just  one  common  SAP  enterprise  controlling  all 
the  logistics  data  and  managing  the  interfaces  to  external  sources  that  have  technical  data 
or  information  of  value  to  those  involved  in  the  life  cycle  of  Army  equipment  and 
supplies.  Integrating  the  LMP,  PLM+  and  GCSS-Army  will  achieve  the  overall  vision  of 
SALE  which  is  “A  fully  integrated  knowledge  environment  that  builds,  sustains,  and 
generates  Warfighting  capability  through  an  integrated  logistics  enterprise  based  upon 
collaborative  planning,  knowledge  management,  and  best  business  practices”  [55],  The 
teaming  arrangement  between  the  Army  and  CSC  to  achieve  a  SALE  running  on  an  SAP 
ERP  is  the  future  of  Army  logistics.  It  is  anticipated  that  this  will  be  realized  with  full 
operational  capability  in  2014. 

D.  DEFENSE  LOGISTICS  AGENCY 

Established  in  1961,  the  Defense  Logistics  Agency  (DLA)  falls  under  the  control 
of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics 
(USD/AT&L)  [56],  The  role  of  DLA  in  the  DOD  is  as  a  centralized  intermediary  supply 
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support  agency  that  procures  consumable  items  from  the  commercial  market  and  then 
distributes  those  items  to  the  separate  service  components.  “DLA’s  critically  important 
role  in  national  security  is  clearly  reflected  in  the  fact  that  the  military  services  rely  on  the 
agency  for  100  percent  of  their  subsistence  items,  medical  material,  construction  and 
barrier  material,  footwear  and  protective  garments... all  the  essentials  of  personal 
readiness”  [57].  For  the  major  end-items  that  the  military  services  fly  and  drive  such  as 
planes,  tanks,  planes,  and  trucks,  DLA  provides  close  to  95  percent  of  the  repair  parts  that 
are  required  to  keep  these  items  operational.  The  agency  is  able  to  accomplish  its 
mission  through  a  requisitioning  system  where  the  customers  (military  services) 
determine  their  consumable  requirements  and  then  submit  orders  to  DLA.  Depending 
upon  the  material  requested,  the  order  will  be  forwarded  to  one  of  four  supply  centers  for 
action.  In  the  U.S.,  the  four  supply  centers  operated  by  DLA  are  [56]: 

1.  Defense  Supply  Center  Columbus,  Ohio,  which  is  responsible  for  land, 
maritime,  and  missile  support; 

2.  Defense  Energy  Support  Center,  Fort  Belvoir,  Virginia,  the  lead  center  for 
comprehensive  energy  solutions,  such  as  contract  support  and  the 
management  of  petroleum-based  fuels; 

3.  Defense  Supply  Center,  Richmond,  Virginia,  which  is  responsible  for  air, 
aviation,  and  space  support;  and 

4.  Defense  Supply  Center,  Philadelphia,  Pennsylvania,  the  lead  center  for  troop 
support  items,  such  as  food,  clothing,  and  medical  supplies. 

Upon  receiving  a  requisition  at  a  supply  center,  the  center  will  meet  the  need  in  one  of 

two  ways.  It  will  either  be  directly  shipped  or  released  from  the  commercial  vendor  who 

provides  the  material  or  fuel,  or  it  will  be  distributed  to  the  customer  out  of  one  of  the 

DLA’s  owned  distribution  depot. 
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Vendors 


Figure  3.9.  DLA’s  Supply  Chain  Management  Process  (From:  [56]) 

In  addition  to  supporting  military  end-items  while  they  are  in  operation,  the  DLA 
is  also  instrumental  when  the  items  reach  the  end  of  their  lifecycle.  At  the  end  of  military 
equipments  “functional  life”  or  when  it  is  no  longer  of  value  to  the  owning  organization, 
it  is  turned  over  to  a  DLA  Defense  Reutilization  and  Marketing  Office  (DRMO)  for 
reuse,  reutilization,  or  disposal. 

1.  Business  System  Modernization 

As  the  “...bridge  between  the  warfighter  and  the  American  industrial  base...” 
[57],  it  was  clear  to  DLA  leadership  when  the  QDR  and  DRI  were  published  that  the 
agency  was  going  to  play  a  key  part  in  “focused  logistics”.  Prior  to  the  release  of  these 
documents,  DLA  had  concentrated  on  being  a  manager  of  the  physical  inventories  that  it 
carried  in  controlled  depots.  Since  the  focus  was  internal,  the  systems  used  were  also 
developed  internally.  The  future  of  DOD  logistics  that  was  mapped  out  in  the  QDR  and 
DRI  shifted  the  focus  of  DLA  from  an  inventory  management  mindset  to  a  supply  chain 
management  mindset  [58].  Due  to  the  fact  that  DLA  holds  such  a  pivotal  position  in  the 
DOD  supply  chain,  “focused  logistics”  would  never  become  a  reality  if  the  Agency 
continued  to  rely  on  the  thirty  year  old  Standard  Automated  Material  Management 
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System  (SAMMS)  and  Integrated  Subsistence  Management  System  (ISMS).  When 
compared  to  industry,  DLA  is  a  massive  enterprise  with  a  scope  of  business  that  includes 
[57]: 

•  54,000  Requisitions/Day 

•  8,200  Contracts/Day 

•  Number  54  on  the  Fortune  500 

•  Number  2  in  Top  50  Distribution  Warehouses 

•  26  Distribution  Depots 

•  5.2  Million  Items 

•  24.7  Million  Annual  Receipts  and  Issues 

With  supply  chain  statistics  similar  to  the  behemoths  of  industry,  the  logical  decision  was 
for  DLA  to  look  to  industry  for  answers  on  how  to  reduce  inventory,  deliver  faster  and 
lower  IT  costs. 

In  July  1998  DLA’s  Business  System  Modernization  (BSM)  program  was  bom 
with  the  establishment  of  the  Modernization  Executive  Board  (MEB).  The  top-level 
objectives  of  the  board  were  [59]: 

•  Replace  Legacy  Systems  with  commercial-off-the-shelf  (COTS)  software. 

•  Reengineer  by  fielding  Best  Practices. 

•  Improve  customer  service  by  collaborating  with  suppliers  and  customers. 

•  Provide  Best  Value  Solutions. 

•  Provide  the  training,  experience,  and  opportunity  to  succeed. 

Following  the  ERP  life  cycle  toward  achieving  these  objectives,  the  first  thing  the 
MEB  did  was  conduct  a  course  of  action  analysis  to  determine  if  an  ERP  was  an 
appropriate  solution  to  transition  DLA  from  inventory  manager  to  supply  chain  manager. 
Having  completed  the  exploratory  phase  in  January  of  1999,  DLA’s  ERP  project  team 
began  process  mapping  in  April  of  1999  to  compare  the  DLA’s  traditional  business 
processes  versus  the  ERP  business  processes.  In  the  summer  of  1999,  ERP  vendors 
demonstrated  how  they  would  perform  DLA’s  business  functions.  The  system 
requirement  were  further  refined  in  the  Fall  of  1999  and  on  December  21st,  1999,  the 
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DOD  approved  DLA  to  move  forward  with  the  project  and  award  a  contract  to  a  systems 
integration  partner  [56].  Accenture  was  selected  as  the  integrator  for  the  BSM  in  August 
of  2000  and  awarded  a  $700  million  contract  to  help  DLA  institute  an  enterprise-wide 
system  [60], 

2.  The  DLA’s  Plan  to  Modernize 

To  distinguish  between  the  different  categories  of  supplies,  the  DOD  had 
separated  the  military  supply  system  into  a  class  of  supply.  The  classes  of  supply  are 
[57]: 

•  Class  I  (Subsistence) 

•  Class  II  (Clothing  and  Textiles) 

•  Class  III  (Bulk  Petroleum) 

•  Class  IV  (Construction  and  Barrier  Materials) 

•  Class  V  (Ammunition) 

•  Class  VI  (Personal  Demand  Items) 

•  Class  VII  (Major  End  Items) 

•  Class  VIII  (Medical  Material) 

•  Class  IX  (Repair  Parts) 

•  Class  X  (Non-military  requirements) 

In  the  DLA’s  implementation  phase  one  of  the  BSM  life  cycle,  the  plan  called  for 
capturing  the  core  processes  related  to  the  classes  listed  with  the  exception  of  Class  III 
(bulk  petroleum),  Class  V  (ammunition),  Class  VI  (personal  demand  items),  Class  VII 
(major  end  items),  and  Class  X  (non-military  requirements).  Class  V,  VI,  VII,  and  X 
have  never  been  the  responsibility  of  DLA.  Class  III  supplies  were  to  be  handled  by  the 
Fuels  Automated  System  (FAS).  Also  a  COTS  software  package,  the  FAS  system  was 
started  as  a  parallel  program  to  the  BSM  but  it  was  developed  solely  to  help  DLA  manage 
$5  billion  worth  of  petroleum  contracts  each  year  [58].  Not  including  petroleum,  the 
BSM  blueprint  was  designed  so  that  the  ERP  would  fulfill  DLA’s  core  business 
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processes  relating  to  planning,  procurement,  order  fulfillment,  and  financial  management 
for  the  other  classes  of  supplies  managed. 
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Figure  3.10.  BSM  Business  Blueprint  (From:  [59]) 

Like  the  Army  the  Navy,  DLA  selected  SAP  R/3  software  for  the  BSM  ERP. 
Additionally,  Manugistics  and  PD2  software  was  also  chosen  to  supplement  the  SAP 
software.  A  Manugistics  package  was  bought  to  manage  demand  history/forecast, 
develop  the  time  phased  inventory  plan,  create  the  supply  plan,  evaluate  demand  plan 
performance  and  optimize  the  distribution  network.  PD2  was  procured  to  manage  vendor 
master  records,  purchase  requisitions  and  solicitations.  It  was  also  to  be  used  for 
converting  the  supply  plan  and  evaluating  quotes.  By  purchasing  these  separate  software 
platforms,  DLA  felt  that  it  had  achieved  two  of  its  top  objectives:  replace  legacy  systems 
with  commercial-off-the-shelf  (COTS)  software  and  provide  best  value  solutions. 

Within  each  core  business  process,  reengineering  targets  were  established  for  the 
ERP  so  that  the  project  would  achieve  two  other  top  level  objectives:  reengineer  by 
fielding  best  practices  and  improve  customer  service  by  collaborating  with  suppliers  and 
customers.  For  the  planning  process  the  goals  for  reengineering  included:  demand  for 
items  should  be  set  by  the  customer,  a  time-phased  inventory  plan,  and  a  budget  based  on 
that  plan.  In  procurement,  the  objectives  were  set  at:  tracking  supplier  performance  and 
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supplier  management,  web-based  procurement,  and  paying  vendors  upon  receipt  of 
material.  Financial  management  was  concerned  with:  FFMIA  compliance,  financials 
integrated  with  business  transactions,  and  a  change  in  inventory  valuation  methodology. 
Finally,  to  improve  order  fulfillment,  DLA  wanted  the  ERP  to  provide:  time  definite 
delivery,  variable  pricing,  on-line  account  visibility  and  most  importantly,  to  deliver 
material  to  the  customer  as  promised.  Requirements  for  the  system  were  written  so  that 
scenarios  could  be  run  to  test  if  these  reengineering  objectives  had  or  had  not  been  met  by 
the  software.  Originally,  the  BSM  project  team  scheduled  full  operational  capability  for 
the  BSM  in  2005.  To  successfully  move  forward  through  the  aggressive  schedule  that 
was  established,  the  system  had  to  meet  more  than  eighty  percent  of  the  functional 
requirements  in  the  operational  requirements  document  (ORD).  Between  2001  and  2005, 
the  program  did  fall  slightly  behind  schedule.  The  actual  schedule  the  BSM  followed  is 
outlined  below. 
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Figure  3.11.  BSM  Timeline  to  Date  (From:  [59]) 
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3.  Phase  II  and  Future  Projects 

At  the  outset  of  the  BSM,  DLA  intended  to  go  beyond  phase  I  of  the  ERP  life 
cycle.  As  early  as  2001,  there  was  talk  of  transitioning  into  implementation  phase  II  and 
beyond  of  the  life  cycle  at  the  conclusion  full  operational  capability  (FOC)  with  the  BSM 
[59].  FOC  for  the  BSM  was  achieved  in  late  2006  and  DFA  is  currently  working  hard  to 
progress  into  implementation  phase  II  and  beyond  as  well  as  making  plans  for  the 
extending  value  phase  of  the  ERP  life  cycle.  Eight  key  initiatives  have  been  started  to 
help  DLA  work  toward  the  vision  of  being  a  critical  enabler  of  “focused  logistics.” 
These  eight  initiatives  are  [57]: 

a.  Customer  Relationship  Management  ( CRM) 

An  extension  of  the  ERP,  a  CRM  system  will  help  DLA  structure  and 
standardize  customer  relations  so  that  issues  are  resolved  in  a  timely  and  effective 
manner.  A  CRM  is  capable  of  doing  this  because  it  establishes  a  single  enterprise-wide 
process  for  classifying  customer  issues  and  then  managing  those  issues  through 
resolution.  The  goal  of  a  CRM  is  not  just  handling  complaints  and  requests  for  status, 
they  also  provide  sales  and  marketing  services  as  well.  By  implementing  a  CRM  system 
DLA  is  anticipating: 

•  Increased  knowledge  of  customer’s  needs. 

•  Easier  customer  access  to  DLA. 

•  More  timely  and  accurate  reporting  on  key  customer  metrics. 

•  Tailored  solutions  based  on  customer  unique  needs. 

•  Enhanced  ability  to  improve  readiness  and  customer  satisfaction  at  a 
reduced  cost. 

•  Increased  ability  to  support  DOD  strategies  of  Focused  Logistics. 

•  Increased  effectiveness  in  managing  customer  expectations  and  agency 
investments. 

•  Enhanced  collaboration  through  collection  and  sharing  information  across 
the  enterprise. 

•  Reduced  customer  complaints. 
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b.  Supply  Relationship  (SRM) 

Also  an  extension  to  the  ERP,  an  SRM  system  enhances  the  ERP  by 
delivering  improved  communication  with  suppliers  so  DLA  can  streamline  the  supply- 
chain  and  reduce  inventory  by  having  products  shipped  directly  from  vendor  to  customer. 
To  make  strong  customer/supplier  relationships  requires  a  great  deal  of  trust  between 
organizations  and  an  SRM  system  helps  to  build  that  trust  by  providing  DLA  “...more 
accurate  insight  into  suppliers’  capabilities  and  suppliers  with  more  insight  into  DLA’s 
needs”  [57],  An  essential  enabler  of  this  relationship  is  the  Electronic  Data  Interchange 
(EDI)  which  links  vendors  and  DLA  so  that  requisitions  can  be  passed  straight  to  vendors 
for  delivery  without  the  need  for  the  material  to  be  received  and  redistributed  by  DLA. 
Also,  a  SRM  system  helps  to  track  vendor  performance  so  the  Supply  Chain  Alliances 
(SCA)  can  be  built  with  the  vendors  that  habitually  deliver  quality  products  and  services. 
All  of  the  benefits  to  an  SRM  fall  under  the  SRM  umbrella. 


■Performance  Based  Logistics 
•Prime  Vendors 


Figure  3.12.  SRM  Umbrella  (From:  [57]) 

Over  the  course  of  the  next  several  years,  it  is  expected  that  DLA’s  SRM  will: 

•  Reduce  delivery  times  and  total  ownership  costs 

•  Provide  inventory  savings 

•  Increase  two-way  communication  with  suppliers 

•  Leverage  buying  power  across  the  enterprise 
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c.  Distribution  Planning  and  Management  System  (DPMS) 

The  DPMS  is  the  delivery  vehicle  for  dramatically  improving  the  shipping 
processes  used  to  get  material  into  the  hands  of  the  warfighters.  Using  a  combination 
COTS  and  government-off-the-shelf  (GOTS)  software,  the  DPMS  will  manage  the 
movement  of  material  in  the  Continental  United  States  (CONUS)  and  outside  the 
Continental  United  States  (OCONUS).  Customers  and  vendors  alike  will  be  linked  into 
the  DPMS  and  provided  real  time  visibility  of  the  location  of  their  inbound  and  outbound 
material.  Such  visibility  will  increase  the  confidence  of  all  parties  that  material  will 
arrive  at  the  time  promised.  It  is  also  predicted  that  the  DPMS  will  allow  for  the  shifting 
of  material  in  route  so  that  the  prioritized  end-user  is  receiving  the  material  they  need  to 
fight.  Customer  Wait  Time  (CWT)  will  be  reduced  and  Time  Definite  Delivery  (TDD) 
will  be  a  reality. 
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Figure  3.13.  DPMS  Program  Architecture  (From:  [57]) 
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d.  Integrated  Data  Environment  (IDE) 

A  centralized  repository  for  all  the  of  the  DOD’s  supply  chain 
management  data  is  needed  so  that  costly  system-to- system  data  interfaces  can  be 
reduced.  That  is  the  purpose  of  the  IDE.  It  will  function  as  the  authoritative  source  of 
logistics  information  and  all  of  the  other  logistics  automated  information  systems  will 
access  it  to  retrieve  the  information  they  need  to  support  the  logistics  enterprise. 
Information  such  as  the  correct  location  of  a  unit  will  be  maintained  in  the  IDE  so  that 
material  is  delivered  to  the  right  place.  IDE  will  eliminate  the  need  for  such  information 
to  reside  in  multiple  systems. 

e.  National  Inventory  Management  Strategy  (NIMS) 

In  an  effort  to  break  down  the  barrier  between  the  wholesale  and  retail 
levels  of  supply  in  the  DOD,  DLA  has  created  the  vision  for  NIMS.  Designed  to  track 
consumable  supplies  from  the  wholesale  level  to  the  point  where  the  item  is  handed  off  to 
the  ultimate  customer,  NIMS  will  establish  a  single  inventory  of  all  consumable  stock  so 
that  DLA  can  tailor  stocks  by  site  thereby  improving  customer  support.  No  longer  will 
the  wholesale  level  lack  visibility  of  what  is  being  kept  at  the  retail  level.  Historically, 
this  lack  of  visibility  has  resulted  in  redundant  inventories  being  kept  at  both  levels 
because  it  is  unknown  what  is  where.  A  cornerstone  of  the  NIMS  concept  is  that  DLA 
would  own  the  inventory  no  matter  where  it  is  stored  until  it  is  sold  off  when 
requisitioned  by  an  end-user. 
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DLA  Consumable  Items 


DLA,  service,  and  site  will 
negotiate  inventory 
management  solutions, 
creating  a  tailored  logistics 
solution  by  site. 

DLA  owns  the  inventory 
investment  to  end-user  point 
of  sale. 

Retail  pass-through  charges 
for  DLA  materiel  are 
eliminated. 

End  User  End  User 

Old  Way  NIMS  Way 

Figure  3.14.  The  NIMS  Vision  (From:  [57]) 

f.  Global  Stock  Positioning  (GSP) 

GSP  is  an  initiative  to  reduce  the  number  of  distribution  centers  necessary 
to  support  DLA’s  mission.  It  is  a  consolidation  effort  that  is  being  undertaken  because  of 
the  reduced  levels  of  inventory  that  will  be  carried  as  result  of  the  ERP.  The  goal  of  the 
GSP  is  to  maintain  the  inventory  that  is  carried  at  the  right  locations  so  the  supply  system 
is  responsive  to  customer  demands.  With  the  GSP,  there  will  be  an  increase  in  the 
number  of  combined  distribution  centers  supporting  co-located  customers.  “By 
implementing  the  GSP,  DLA  is  ensuring  that  the  right  inventory  is  at  the  right  locations 
to  meet  warfighter  requirements.  The  result:  reduced  costs,  reduced  customer  wait  times, 
improved  warfighter  readiness  and  a  reduced  logistics  footprint”  [57], 

g.  Product  Data  Management  Initiative  (PDMI) 

Currently,  most  of  the  technical  manuals  relating  to  the  products  DLA 
buys  are  kept  manually.  The  PDMI  is  aimed  at  automating  the  maintenance  manuals  and 
operating  procedures  for  the  products  DLA  manages.  Once  automated,  the 
discontinuities  of  the  manual  documents  will  be  eliminated  and  customers  will  have 
access  to  the  most  up  to  date  technical  data  about  an  item  being  ordered.  Programs  such 
as  the  PDMI  have  proven  successful  in  the  commercial  sector  and  through  the 
reengineered  business  processes  and  COTS  software,  DLA  hopes  to  have: 


-Stockage 
Levels 
-Critical  Items 
-Infrastructure 
Agreements 
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•  a  single  virtual  workspace  for  all  technical  users; 

•  a  standardized,  enterprise-wide  business  process  supporting  all  product 
and  product  data  specialists  and  related  staff; 

•  a  fully  automated,  modernized,  and  re-engineered  set  of  technical  business 
processes  that  will  significantly  contribute  to  and  improve  DLA’s  overall 
cross-function  and  cross-process  responsiveness  to  its  customers; 

•  automated  management  of  technical  and  product  data  used  in  support  of 
DLA  managed  items; 

•  technical  business  processes,  including  links  to  technical  specifications, 
drawings,  manuals  and  transaction  data; 

•  complete  visibility  into  all  product  and  technical  data  associated  with  DLA 
items,  including  the  ability  to  provide  this  visibility  to  DLA’s  customers  in 
coordination  with  the  CRM  initiative; 

•  a  reliable  ability  to  exchange  documents  and  forms  with  service  design 
activities; 

•  a  reliable,  robust,  and  seamless  interface  with  BSM’s  SAP  application, 
which  will  enable  true  cross-process  functional  flows; 

•  a  reliable,  robust  and  wholly  automated  document  management  function  to 
support  both  PDM1  and  the  BSM  suite  of  applications,  including  bid  set 
and  bill  of  material  (BOM)  support; 

•  a  replacement  for  Joint  Engineering  Data  Management  Information  and 
Control  System  (JEDM1CS)  based  on  contemporary  technologies;  and 

•  a  COTS  and  standards  based  application  that  will  provide  cost-effective 
sustainment  and  enhancement  capabilities. 

h.  Reutilization  Modernization  Program  (RMP) 

The  last  initiative  that  will  work  to  modernize  the  complete  life  cycle  of 
the  material  procured  by  DLA  is  the  RMP.  Created  to  replace  the  Defense  Reutilization 
and  Marketing  Services  (DRMS)  current  IT  systems,  the  RMP  is  COTS  software  that  will 
easily  fit  together  with  the  BSM  ERP.  When  the  RMP  is  in  place,  DLA  will  have  digital 
access  to  all  the  data  about  an  item  from  procurement  to  disposal. 

E.  THE  UNITED  STATES  MARINE  CORPS 

While  the  Navy,  Army  and  DLA  were  getting  their  separate  ERP  programs 
started  in  the  late  1990s,  the  Marine  Corps  delayed  starting  any  projects  until  studies 
were  done  to  analyze  the  problems  with  the  Marine  Corps’  current  logistics  environment. 
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Named  the  Logistics  Information  Resource  (Log  IR)  Strategic  Plans,  the  studies 
concluded  in  1998  that  much  like  the  other  service  branches,  the  Marine  Corps  was  also 
running  old,  non-integrated  systems  that  were  not  keeping  pace  with  the  modem  logistics 
practices  of  the  public  sector.  Specifically,  the  non-integrated,  stovepiped  processes  and 
systems  resulted  in  a  complex  logistics  chain  designed  to  support  peacetime  operations. 
In  war,  the  processes  used  to  support  combat  operations  change  and  therefore,  the  Marine 
Corps  support  personnel  are  required  to  leam  new  processes  and  systems  while  moving 
with  the  combat  forces  engaged  in  battle. 
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Support  (Supplier  1)  Unit 

(Supplier  2) 
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Support  (Supplier  1)  Unit 
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Multiple  complex  processes 


Single  complex  process 


Non-integrated.  stove-piped,  independent  processes 


Figure  3.15.  Current  Logistics  Chain  in  Garrison  and  Deployed  (From:  [61]) 

Additional  problems  with  the  Marine  Corps’  logistics  chain  include  [61]: 

•  Multiple  complex  processes  exist  that  must  be  managed  at  the  supported 
unit  level.  Numerous  specialized  systems  and  skills  are  required,  placing 
the  burden  on  the  warfighters  to  fulfill  their  own  logistics  needs  and 
detracting  form  their  fundamental  core  competency-to  execute  combat  or 
combat  support  operations. 

•  Inadequate  information  visibility  exists  along  the  Marine  Corps  logistics 
chain  to  support  informed  logistics  planning  and  execution  decisions. 
Today  supported  units  do  not  have  visibility  regarding  status  of  their 
requests  for  products,  and/or  services,  service  capacity  (e.g.,  people, 
equipment)  available  to  fulfill  their  requests,  and  inventory  available 
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within  and  outside  the  Marine  Corps  (e.g.,  Defense  Logisitics  Agency 
(DLA)  and  vendor  inventory)  to  fulfill  their  requests. 

•  This  lack  of  near  real-time  information  sharing  is  leading  to  demand 
uncertainty  and  mountains  of  excess  inventory  (i.e.,  safety  stock). 

•  Inventory  is  managed  and  positioned  by  class  of  supply  and  according  to 
doctrine  and  policy,  with  very  little  understanding  of  the  importance  of  the 
individual  end  item  to  mission  accomplishment  and  the  ability  of  the 
global  supply  environment  to  support  the  demand.  This  results  in  large 
amounts  of  redundant  and  layered  inventory  (the  “Iron  Mountain”)  being 
maintained  along  the  logistics  chain. 

•  Numerous  and  conflicting  metrics  exist,  with  most  not  aligned  to  Marine 
Corps  strategic  goals. 

1.  The  Blueprint 

Once  the  problems  with  the  logistics  environment  were  identified,  the  Marine 
Corps  decided  that  a  logistics  operational  architecture  (Log  OA)  needed  to  be  designed  to 
remedy  the  situation.  In  December  2000,  work  on  the  Log  OA  got  started  and  shortly 
after  initiation,  it  was  determined  that  best  architecture  would  be  one  that  can  be  used  in 
both  garrison  and  deployed. 


Single  process  for  garrison  and  deployed  operations 


Supplier  N  Supplier  1  Customer 
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Logistics 

Provider 


Supported 
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Integrated,  cross-functional,  end-to-end  process 


Figure  3.16.  Future  Logistics  Chain  in  Garrison  and  Deployed  (From:  [61]) 

Thus,  the  resulting  architecture  called  for  a  single  process  that  could  deliver  material 
from  “factory  to  foxhole”  [61]. 
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To  complete  the  envisioned  integrated  architecture,  the  Marine  Corps  Logistics 
Modernization  (Log  Mod)  program  was  started  in  late  2003  with  the  launching  of  six 
initiatives  encompassing  the  different  aspects  of  the  program  [61]. 

a.  Log  OA 

The  first  initiative  was  an  expansion  of  the  original  Log  OA  and  was 
created  to  map  out  the  details  of  a  single  end-to-end  process  for  Logistics  Chain 
Management  (LCM)  based  upon  the  recommendations  of  the  commercial  sector.  An 
expanded  Log  OA  is  the  foundation  for  the  Log  Mod  as  a  whole  because  it  encompasses 
all  of  the  actions  and  interfaces  that  must  take  place  to  fill  a  request.  The  Log  OA  also 
blueprints  the  communication  assets  and  personnel  structure  that  should  be  in  place  to 
implement  commercial  logistics  best  practices.  Finally,  the  Log  OA  includes  a  plan  for 
capacity  management  analysis  for  products,  services  and  transportation  assets  as  well  as  a 
plan  for  In-Transit  Visibility  (ITV)  and  Total  Asset  Visibility  (TAV). 

b.  Log  C2 

To  route  request  and  provide  the  visibility  to  all  the  parties  involved  in  the 
Log  OA,  an  extensive  telecommunications  network  must  be  planned  for.  The  Log  C2  is 
the  initiative  that  was  started  to  cover  this  portion  of  the  Log  Mod  program. 

c.  CSSR/R 

Historically,  three  active  duty  Force  Service  Support  Groups  (FSSGs) 
support  all  Marine  Corps  ground  logistics  for  the  three  Marine  Expeditionary  Forces 
(MEFs).  Each  of  the  FSSGs  is  uniquely  organized  to  support  the  different  command 
structures.  This  arrangement  is  not  consistent  with  the  requirements  of  the  Log  OA. 
Therefore,  the  Combat  Service  Support  Rename/Reorganize  (CSS  R/R)  initiative  was 
started  to  rename  and  reorganize  the  FSSGs  to  align  with  the  Log  OA.  It  is  also  expected 
that  the  CSS  initiative  will  provide  more  consistency  to  the  FSSGs  in  terms  of  size  and 
structure  because  under  the  CSS  R/R  framework,  the  organizational  structure  is  identical 
for  I,  II  and  III  MEF. 
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d. 


MAGTF  Distribution 


The  Marine  Air-Ground  Task  Force  (MAGTF)  Distribution  initiative  was 
started  to  oversee  all  the  aspects  of  physical  material  flow.  Due  to  the  fact  that  a  critical 
requirement  of  the  Log  OA  is  ITV,  every  delivery  platform  in  the  end-to-end  supply 
chain  must  be  integrated  to  provide  visibility  of  assets  as  they  travel  the  path  to  and  from 
the  customer.  MAGTF  Distribution  is  responsible  for  making  that  integration  happen  so 
that  all  transportation  assets  within  the  MAGTF  and  external  to  the  MAGTF  are  linked 
into  the  architecture  to  provide  updates  on  material  location. 

<?.  ROM 

Poor  maintenance  effectiveness  and  a  lack  of  available  operational 
equipment  has  been  the  result  of  the  Marine  Corps’  five  Echelons  of  Maintenance 
(EOMs)  for  ground  equipment  [61].  Consequently,  the  Realignment  of  Maintenance 
(ROM)  initiative  institutes  the  three  levels  of  maintenance  used  in  the  air  side  of  the 
MAGTF.  Under  the  ROM,  there  will  be  an  Operator/Crew  level,  a  Field  level  and  a 
Sustainment  level. 
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Majority  of 
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1  +  2,  3  &  4  (-)  4(-)  &  5 
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Figure  3.17.  The  3  Levels  of  Maintenance  (From:  [61]) 

Every  piece  of  ground  equipment  currently  in  use  will  be  realigned  to  the  three  levels  of 
maintenance  system.  Moreover,  all  new  acquisitions  of  ground  equipment  must  also 
adhere  to  the  three  level  system. 
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f.  ROS 

Covering  the  inventory  management  aspect  of  the  Log  Mod  is  the 
Realignment  of  Supply  (ROS)  initiative.  In  the  1960s  through  the  1980s,  order 
processing  cycles  took  a  long  time.  Consequently,  the  Marine  Corps  invested  heavily 
into  stocking  material  at  the  different  levels  of  the  supply  chain  to  ensure  availability  of 
material.  Managing  these  large  inventories  is  cumbersome  and  requires  a  substantial 
outlay  of  funds.  This  problem  led  to  the  ROS  so  that  the  Marine  Corps  can  focus  on 
order  management  and  move  away  from  inventory  and  warehouse  management.  The 
targeted  objectives  for  ROS  are  [62]: 

•  Remove  the  responsibility  for  request  management  from  the  supported 
unit  to  allow  it  to  concentrate  on  its  primary  mission,  implement  request 
management  [end-user  function]  and  order  management  functions 
[supporting  supply  agency  function], 

•  Centralize  the  responsibilities  for  order  fulfillment  and  capacity 
management  of  both  inventory  and  procurement  in  one  supporting  unit  for 
each  MAGTF. 

•  Manage  product  inventory  in  the  logistics  chain  according  to  its  criticality 
to  the  mission  and  its  relative  availability.  Do  not  stock  easy  to  obtain 
non-critical  items  and  make  heavier  use  of  outside  sources  (e.g.  DLA  and 
vendor  managed  inventory)  for  these  items. 

•  Track  orders  and  provide  in-transit  visibility  and  total  asset  visibility 
across  the  logistics  chain.  Introduce  performance  management  for 
inventory  and  product  order  management. 

•  Integrate  ROS  with  related  Navy,  DLA  and  Joint  programs  such  as  Naval 
Logistics  Integration,  DLA  NIMS,  JEMMS,  etc. 

•  Integrate  supply  with  distribution  according  to  best  logistics  chain 
management  practices. 

•  Introduce  enterprise-level  inventory  and  inventory  capacity  planning  to 
optimize  the  flow  and  minimize  costs  across  the  logistics  chain. 

An  essential  part  of  the  ROS  is  the  integration  of  the  new  supply  chain  processes 
with  organizations  external  to  the  Marine  Corps.  Due  to  the  fact  that  a  large  part  of  the 
Marine  Corps  ground  equipment  is  common  to  the  Army,  the  Log  Mod  is  going  to  have 
to  communicate  with  the  Army’s  LMP  in  order  to  requisition  material  from  the  wholesale 
level  for  the  Army/Marine  Corps  common  operational  assets.  Primarily,  the  Log  Mod  is 
concentrating  on  the  retail  level  of  supply  because  with  the  ROS,  it  is  hoping  to  abandon 


70 


as  much  inventory  management  and  warehousing  functions  as  possible.  By  relying  on 
the  Army’s  LMP  and  DLA’s  NIMS  initiatives,  there  is  great  potential  for  a  massive 
reduction  of  Marine  Corps  owned  inventory.  There  are  nearly  500,000  items  unique  to 
the  Marine  Corps  that  will  have  to  be  planned  for,  but  the  Corps  will  be  looking  for  DLA 
and  the  individual  vendors  to  manage  the  inventory  for  most  of  these  items  [61].  As  was 
stated  in  the  list  of  objectives,  the  Marine  does  not  want  to  “...stock  easy  to  obtain  non- 
critical  items...”  All  that  will  be  carried  in  inventory  by  the  Marine  Corps  is  equipment 
unique  to  the  Corps  that  is  hard  to  get.  Aviation  material  for  the  Marine  Corps’  aviation 
assets  is  not  planned  for  in  the  ROS  because  Marine  Corps  aviation  is  funded  directly  by 
the  Navy.  Hence,  any  changes  that  take  place  with  the  Navy  ERP  that  affect  Naval 
aviation  will  also  apply  to  Marine  Corps  aviation. 

2.  Processes,  Technology,  and  People 

To  tackle  the  objectives  set  out  in  the  Log  Mod,  a  plan  has  been  developed  that 
includes  a  three  prong  assault  including  processes,  technology,  and  people.  It  has  been 
determined  that  these  are  the  three  things  that  must  fundamentally  change  in  the  Marine 
Corps  for  the  Log  Mod  to  succeed. 


Ligure  3.18.  Change  Elements  of  Log  Mod  (Prom:  [61]) 

The  Marine  Corps  is  looking  for  logistics  processes  that  “...can  support  any  unit, 

in  any  situation,  anywhere”  [61].  These  processes  are  depicted  in  the  Log  OA  and 

provide  the  architectural  framework  for  streamlining  the  logistics  chain  to  support  future 

Marine  Corps  operations.  Changing  processes  must  be  supported  with  an  investment  in 
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IT.  In-line  with  the  Army’s  naming  convention,  the  Marine  Corps  has  adopted  the  name 
Global  Combat  Support  System  (GCSS)  as  the  name  for  the  portfolio  of  COTS  systems 
that  will  be  implemented  to  replace  the  current  logistics  systems.  Given  that  the  Marine 
Corps  GCSS  and  the  Army’s  GCSS  are  both  focused  on  the  retail  piece,  the  name  is 
fitting.  GCSS-MC  is  the  official  name  of  the  Marine  Corps  system  so  that  it  is 
distinguishable  from  the  Army’s.  Finally,  since  the  new  processes  and  systems  must  be 
run  by  people,  the  personnel  structure  and  training  in  the  Marine  Corps  must  change  so 
that  it  fits  with  the  new  processes  and  technology.  Moreover,  the  Marine  Corps  Log  Mod 
team  recognizes  change  management  must  be  incorporated  into  the  program  so  that  it  can 
overcome  the  resistance  that  will  occur  as  a  result  of  the  implementation  of  new  business 
processes.  The  change  management  plan  is  covered  in  the  people  portion  of  the  overall 
strategy. 

3.  The  Timeline 

An  incremental  timeline  has  been  instituted  with  the  Log  Mod  being  completed  in 
blocks  so  that  it  aligns  with  the  Program  Objective  Memorandum  (POM)  financial 
practice  that  is  used  in  the  U.S.  Government. 

Improved  Processes 


1 

f 


Increased  Combat  Effectiveness 

Figure  3.19.  GCSS-MC  Capabilities  (From:  [61]) 

Block  one  of  GCSS-MC  provides  the  initial  capability  of  the  system  and  includes 
such  things  as  the  functionality  to  support  deployed  operations,  inventory  management, 
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maintenance  management,  and  service  management.  Within  block  one,  the  following 
legacy  systems  are  to  be  retired:  Supported  Activities  Supply  System  (SASSY),  Marine 
Corps  Integrated  Maintenance  Management  System  (MIMMS),  PC  MIMMS,  and  Asset 
Tracking,  Logistics,  and  Supply  System  (ATLASS  I)  [62],  The  operational  requirements 
document  for  GCSS-MC  was  completed  in  late  2003  and  it  was  established  as  a  program 
of  record  to  receive  funding  in  the  Fiscal  Year  2004  POM  [63].  All  remaining 
requirements  to  get  block  one  completely  funded  were  completed  in  June  2006  and  the 
program  is  fully  funded  in  the  2008  POM.  Currently,  the  Marine  Corps  is  working  the 
requirements  for  block  two  with  a  scheduled  completion  date  of  June  2008  so  that  it  can 
be  funded  in  POM  10.  Between  July  2008  and  June  2010  block  three  will  be  outlined  for 
funding  in  POM  12.  Full  operational  capability  (FOC)  of  the  Log  Mod  system  as  a 
whole  is  anticipated  by  2015. 

Officially,  it  can  be  said  that  the  Log  Mod  got  underway  in  2003  when  GCSS-MC 
was  established  as  an  ACAT  I  program  of  record.  This  categorization  put  the  Log  Mod 
on  an  equal  footing  with  the  expeditionary  fighting  vehicle.  Once  established  as  a 
program  of  record,  the  Commandant  of  the  Marine  Corps  put  his  endorsement  on  the 
program  in  January  2004  when  he  released  a  Marine  administrative  message,  a  personal- 
for  message,  and  an  all  Marine  Message  (ALMAR)  that  emphasized  the  fact  that  the 
Marine  Corps  “...cannot  improve  the  combat  capability  of  the  MAGTF  without  this 
LOGMOD”  [63].  This  message  caused  an  increase  in  momentum  on  the  part  of  his  staff 
and  in  July  2004,  the  Deputy  Commandant,  Installations  and  Logistics  launched  the  Log 
Mod  Transition  Task  Force  (TTF).  After  developing  the  six  Log  Mod  initiatives  (Log 
OA,  Log  C2,  CSS  R/R,  MAGTF  Distribution,  ROM,  and  ROS),  the  TTF  briefed  the 
Expeditionary  Force  Development  System  (EFDS)  Working  Group  who  in  turn  formed 
an  Assessment  Group  to  write  the  directives  to  begin  implementation. 

With  the  initiatives  in  place  and  the  requirements  detailed,  it  was  time  to  select  a 

software  vendor.  Unlike  the  Army,  Navy,  and  DLA,  the  Marine  Corps  selected  the 

Oracle  e-business  suite  as  their  ERP  of  choice  for  the  Log  Mod  in  August  2004.  It  has 

been  stated  by  the  Program  Manager  for  GCSS-MC  that  Oracle  was  chosen  “...  because 

it  satisfied  the  functional  requirements  more  completely,  provided  greater  flexibility  for 

future  needs,  and  demonstrated  an  understanding  of  the  challenges”  [63].  Shortly  after 
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making  the  decision  on  the  software,  the  hunt  began  for  an  integrator.  The  Marine  Corps 
turned  to  Office  of  the  Secretary  of  Defense  (OSD)  enterprise  software  initiative  (ESI)  in 
order  to  shorten  the  timeframe  for  acquiring  an  integrator.  It  was  estimated  that  using  the 
ESI  save  ninety  days  on  the  selection  process.  The  integrator  search  began  in  November 
2004  and  by  April  2005  Accenture  had  been  chosen  to  help  make  the  Log  Mod  a  reality. 
Progress  has  been  steady  since  the  GCSS-MC  team  was  formed  with  Oracle  and 
Accenture  and  initial  operating  capability  (IOC)  for  block  one  is  expected  in  the  Fall  of 
2008.  For  Fiscal  Years  2003  through  2007,  the  total  cost  for  GCSS-MC  is  $171.7  million 
[64],  [65], 

F.  THE  UNITED  STATES  AIR  FORCE 

Being  the  technologically  savvy  branch  that  it  is,  it  is  somewhat  surprising  that 
the  Air  Force  hesitated  with  their  ERP  program  until  post  Y2K.  Like  the  other  services, 
the  Air  Force  also  recognized  in  the  late  1990s  that  the  seven  hundred  plus  legacy 
systems  in  the  organization’s  combat  support  IT  portfolio  were  not  capable  of  adequately 
tracking  personnel  and  critical  supplies.  The  ten  detailed  weaknesses  of  the  legacy 
systems  that  the  Air  Force  identified  during  that  time  period  include  [66]: 

•  Lack  of  Authoritative  Shared  Data. 

•  Lack  of  Easy  Global  Access. 

•  High  Operations  and  Maintenance  Cost. 

•  No  Common  User  Interface  (UI). 

•  Insufficient  Interoperability. 

•  Hardware  Dependency. 

•  Insufficient  Network  Access. 

•  Limited  Decision  Support  Tools. 

•  Excessive  Functional  Dependency. 

•  [Insufficient]  Visibility. 

However,  instead  of  immediately  starting  a  project  as  was  done  in  the  Navy  and 
Army,  the  Air  Force  followed  the  Marine  Corps  methodology  and  devoted  themselves  to 
defining  the  requirements  and  documenting  the  architecture  to  achieve  the  requirements. 
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1. 


GCSS-AF 


In  December  2001,  the  Air  Force  Material  Command  published  the  Operational 
Requirements  Document  for  the  Global  Combat  Support  System  -  Air  Force  (GCSS-AF). 
The  vision  for  GCSS-AF  is  a  family  of  systems  that  has  the  ability  to  combine  the 
information  of  the  23  combat  support  functional  areas  into  an  integrated  environment  to 
provide  trusted  data  to  all  users.  A  portion  of  the  GCSS-AF  plan  includes  linking 
external  entities  such  as  the  National  Command  Authority,  the  other  service  branches  and 
allied  and  coalition  partners  to  the  integrated  data  to  present  a  common  operational 
picture  to  support  joint  operations.  This  vision  is  diagramed  in  Figure  3.20. 
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Figure  3.20.  GCSS-AF  High-Level  Operational  Concept  Diagram  (From:  [66]) 

2.  ECSS 

From  the  overarching  framework  of  the  GCSS,  the  Air  Force  subdivided  out  the 
logistics  portion  of  the  enterprise  and  titled  it  the  Expeditionary  Combat  Support  System 
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(ECSS).  An  exhaustive  explanation  of  the  ECSS  system  is  not  necessary  because  it 
copies  the  Marine  Corps’  GCSS-MC  program  with  the  only  difference  being  that  it 
includes  the  wholesale  level  of  supply.  As  was  done  by  the  Marine  Corps,  the  Air  Force 
formed  an  architecture  for  the  ECSS  which  they  titled  the  Logistics  Enterprise 
Architecture  (LogEA)  [67],  Also  like  the  Marine  Corps,  the  Air  Force  selected  the 
Oracle  e-business  suite  as  their  ERP  of  choice  for  the  ECSS  and  signed  an  $88.5  million, 
multiyear  contract  with  Oracle  on  October  25,  2005  [68].  Almost  a  year  after  awarding 
the  ERP  contract  to  Oracle,  the  Air  Force  broke  out  of  the  Marine  Corps  mold  when  they 
awarded  a  $627.8  million,  multiyear  contract  on  September  7,  2006  to  the  Computer 
Sciences  Corporation  (CSC)  for  integration  services  [69].  The  ECSS  is  expected  to  be 
fully  operational  by  September  2013  [70]. 
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IV.  PROGRAM  COMPARISON 


A.  JOINT  VISION  2020 

Released  in  June  of  2000,  Joint  Vision  2020  is  the  document  that  the  DOD  is 
currently  using  to  guide  the  future  of  America’s  Armed  Forces.  The  document  builds  and 
expands  upon  the  principles  established  in  Joint  Vision  2010  to  emphasize  the  changes 
that  took  place  in  the  global  environment  between  1997  and  2000.  However,  the 
overarching  strategy  of  full  spectrum  dominance  first  revealed  in  Joint  Vision  2010  is 
carried  forward  in  Joint  Vision  2020  and  it  remains  the  goal  for  the  DOD  to  work  towards 
to  meet  and  defeat  its  adversaries  in  the  future.  Along  with  full  spectrum  dominance,  the 
foundational  pillars  of  dominant  maneuver,  precision  engagement,  full  dimensional 
protection  and  most  important  for  the  DOD’s  ERP  programs,  focused  logistics  are  carried 
forward  in  Joint  Vision  2020  [71]. 

B.  SEA  POWER  21 

To  incorporate  the  Navy’s  capabilities  into  Joint  Vision  2020,  the  Chief  of  Naval 
Operations  published  Sea  Power  21  in  October  2002. 


SEA  POWER  21 


Sea  Shield 


►  Sea  Strike 


Sea  Basing 


Figure  4. 1 .  Sea  Power  2 1  (From:  [72]) 
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Sea  Power  21  is  the  name  of  the  Navy’s  strategic  vision  for  how  it  will  organize, 
integrate,  and  transform  in  the  coming  years  to  meet  the  requirements  of  Joint  Vision 
2020.  Like,  Joint  Vision  2020,  Sea  Power  21  is  made  up  of  foundational  pillars  that  work 
together  to  achieve  the  Navy’s  overarching  strategy  and  correspond  to  the  pillars  of  Joint 
Vision  2020.  In  Sea  Power  21,  the  foundational  pillars  are  Sea  Shield,  Sea  Strike  and  Sea 
Basing.  Sea  Shield  is  the  Navy’s  version  of  full  dimensional  protection  and  Sea  Strike 
covers  dominant  maneuver  and  precision  engagement. 

1.  Sea  Basing 

Sea  Basing  ties  in  with  focused  logistics  and  is  important  because  the  objective  of 
the  pillar  is  to  place  at  sea,  a  network  of  platforms  that  include  strike  ships  (aircraft 
carriers,  frigates,  destroyers,  etc.),  combat  logistics  force  ships,  and  maritime 
prepositioning  ships  that  are  operated  by  the  Military  Sealift  Command.  Modem 
technology  that  facilitates  the  networking  of  these  different  platforms  with 
communication  systems  and  sensors  is  overcoming  the  traditional  view  that  forces  at  sea 
have  a  difficult  time  with  interoperability  due  to  dispersion.  Rather,  the  netted  force  of 
ships  can  be  viewed  as  an  operating  platform  from  which  the  joint  and  coalition 
commander  can  employ  “...offensive  and  defensive  firepower,  maneuver  forces, 
command  and  control,  and  logistics”  [73]. 

There  are  several  reasons  the  Navy  has  placed  Sea  Basing  as  an  integral  part  of 
the  Sea  Power  21  vision.  The  first  reason  is  that  with  bases  at  sea,  there  is  a  force 
available  to  rapidly  respond  to  crises  and  project  power  throughout  the  world.  Secondly, 
a  reduced  footprint  ashore  can  be  achieved  by  leaving  the  command  and  control  (C2)  and 
logistics  assets  aboard  ship.  The  third  reason  is  it  has  been  getting  increasingly  difficult 
for  the  U.S.  forces  to  operate  from  foreign  soil.  Recent  examples  of  this  dilemma  include 
the  trouble  the  U.S.  had  with  Turkey  in  Operation  Iraqi  Freedom  and  the  withdrawal  of 
the  American  military  presence  form  Saudi  Arabia.  Therefore,  by  deploying  forces  from 
the  sea,  the  U.S.  can  avoid  the  political  and  military  obstacles  that  might  obstruct  the 
establishment  of  land  bases.  Lastly,  and  most  importantly,  as  a  concept,  Sea  Basing 
requires  a  substantial  Navy.  Thus,  it  provides  the  Navy  ammunition  in  the  fight  for  the 
precious  tax  dollars  that  all  the  services  are  desperately  vying  for. 
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2.  Joint  Logistics 

To  effectively  compete  for  these  tax  dollars  in  the  post  Goldwater-Nichols 
military,  a  demonstration  of  how  a  capability  is  applicable  in  the  joint  arena  has  become 
paramount.  Consequently,  the  Navy  has  looked  outside  of  itself,  and  incorporated  the  Air 
Force,  Army  and  the  Marine  Corps  into  Sea  Basing.  For  the  Air  Force,  Sea  Basing 
envisions  “...  Air  Force  unmanned  combat  vehicles  surging  to  sea  bases  rather  than 
bedding  down  ashore”  [73],  The  integration  of  the  Army  and  Marine  Corps  is  more 
extensive.  It  is  proposed  that  the  Sea  Bases  can  serve  as  assembly  areas  where  the  Army 
and  Marine  units  deploying  into  a  combat  theater  can  be  married  up  with  the  larger 
weapons  systems  that  are  carried  by  sea.  Upon  the  arrival  of  the  soldiers  and  Marines  on 
ship,  the  weapons  systems  can  be  selectively  retrieved  and  assembled  prior  to  embarking 
the  troops  off  the  ship  and  into  combat.  Not  only  are  the  Sea  Bases  important  to  the 
Army  and  Marine  Corps  for  retrieval  of  equipment,  it  is  also  anticipated  that  they  will  be 
the  source  for  the  critical  sustainability  packages  of  supplies  the  ground  forces  require  as 
they  conduct  combat  operations.  Historically,  the  Navy  has  always  filled  this  role  for  the 
Marine  Corps  but  Sea  Basing  emphasizes  the  importance  of  this  capability  to  reduce  the 
Marine  Corps  footprint  ashore.  The  added  idea  of  having  ships  operate  as  assembly  areas 
for  Army  soldiers  is  what  makes  Sea  Basing  a  departure  from  traditional  operational 
doctrine  [74], 

The  technology  that  will  make  the  Sea  Bases  capable  of  meeting  the  requirement 
for  an  assembly  area  and  supply  point  is  twofold.  First,  the  ships  must  have  the  latest 
advances  in  inventory  management  and  automated  material  handling  systems  so  that  they 
can  locate,  identify  and  retrieve  the  necessary  equipment  while  remaining  at  sea.  Second, 
the  Navy  and  its  ships  has  to  have  a  logistics  system  that  incorporates  modem  supply 
chain  management  initiatives  like  “Just  In  Time”  supply,  Total  Asset  Visibility  (TAV) 
and  In-Transit  Visibility  (ITV)  as  well  as  be  integrated  with  the  Air  Force’s,  Army’s,  and 
Marine  Corps’  logistic  systems  so  that  it  can  make  the  vision  of  Sea  Basing  a  reality  [74], 

C.  TROUBLED  APPROACH 

The  U.S.  National  Command  Authority  (NCA),  the  separate  service  component 
Secretaries  and  Joint  Chiefs  of  Staff  are  trusting  that  the  integration  of  the  separate  DOD 
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ERPs  at  some  point  in  the  future  will  deliver  the  warfighting  support  potential  resident  in 
the  strategic  documents  of  Joint  Vision  2020  and  Sea  Power  21.  Unfortunately,  this  is 
the  only  thing  that  can  be  hoped  for  because  of  the  separate  approaches  that  were  taken 
toward  ERP  when  the  projects  first  got  started  in  the  late  1990s.  During  this  period,  the 
DOD  should  have  established  a  central  ERP  office  and  the  DOD  in  its  entirety  could  have 
been  defined  as  the  enterprise  to  be  covered  by  a  single  ERP. 

1.  Ideal  ERP 

Theoretically,  one  ERP  for  the  entire  DOD  ought  to  be  possible  because  the 
separate  services  logistically  function  in  the  same  way.  For  example,  each  branch  of  the 
military  has  aircraft.  All  aircraft  require  parts  and  maintenance.  The  ideal  situation 
would  be  one  ERP  controlling  the  processes  for  the  supply  of  parts  and  maintenance  on 
aircraft  across  all  the  services.  This  would  allow  service  members  with  similar  functional 
backgrounds  to  work  side  by  side  in  the  joint  operational  arena  without  any  concern  for 
knowledge  barriers  resulting  from  disparate  process  comprehension.  Facilitating  an 
environment  where  Air  Force  supply  clerks  could  order  parts  for  Army  helicopters. 
Marine  jet  mechanics  could  work  on  Air  force  jets  and  so  forth.  Instead,  the  best 
outcome  is  the  separate  ERPs  can  be  connected  at  some  point  in  the  future  to  provide  an 
integrated  view  of  the  entire  DOD’s  data.  While  not  perfect,  the  envisioned  solution  is  a 
drastic  improvement  over  the  current  operating  environment  which  has  soldiers,  sailors, 
airmen  and  Marines  using  unique  logistics  systems  with  no  integration.  The  severe 
problem  with  this  environment  surfaced  recently  in  Operation  Iraqi  Freedom  where 
“...platoons  were  unable  to  locate  the  nearest  MRE’s  (Meals  Ready  to  Eat),  spare  parts 
were  difficult  to  obtain  driving  multiple  re-orders  and  unidentified  supplies  were 
stockpiled  at  significant  cost  without  contributing  to  warfighter  effectiveness”  [5], 

The  first-class  corporations  that  have  successfully  transformed  their  organizations 
using  ERPs  are  those  that  identified  their  common  core  business  functions  and  aligned 
their  ERP  around  those  functions  to  maximize  their  potential.  Notionally,  this  should 
have  been  possible  within  the  DOD.  The  entire  DOD  has  common  characteristics  which 
include  personnel,  equipment,  and  facilities.  Each  one  of  these  characteristics  has 
common  data  points  as  well.  For  example,  all  personnel  have  a  social  security  number, 
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age,  gender,  rank,  etc.  All  equipment  has  a  dimension,  part  number,  national  stock 
number,  name,  etc.  Facilities  have  an  equal  number  of  common  characteristics.  The  core 
business  function  of  the  DOD  involves  leaving  the  facilities  and  transporting  the 
personnel  and  equipment  around  the  world  to  engage  foreign  adversaries.  In  this 
endeavor,  there  are  common  transportation  platforms  as  well  as  a  universal  support 
structure  that  supplies  the  military  both  at  home  and  abroad  with  the  primary  example 
being  DLA.  The  similarities  between  the  service  components  do  not  end  at  their  business 
functions.  A  review  of  the  reasons  discussed  in  Chapter  III  for  each  of  the  services’  and 
DLA’s  choice  to  initiate  an  ERP  project  reveals  that  collectively  they  are  facing  the  same 
problem:  outdated  business  procedures  and  processes  running  on  antiquated  software 
systems. 

By  focusing  on  their  commonality  vice  their  differences,  the  multiple  sectors  that 
form  an  entire  organization  can  achieve  what  is  known  as  conceptual  unity.  The  proof 
that  conceptual  unity  can  be  achieved  by  any  organization  no  matter  how  large  is 
demonstrated  by  the  nation  of  Singapore.  Studies  of  the  country  have  shown  that 
“...Singaporeans  as  a  whole  understood  the  vision  and  mission  of  Singapore”  [5],  The 
embracing  of  conceptual  unity  between  the  government  and  industry  has  led  to  the  label 
“Singapore  Inc”  [5].  Disappointingly,  because  the  DOD  CIO  that  was  appointed  as  a 
result  of  the  Information  Technology  Management  Reform  Act  (ITMRA)  did  not  push 
conceptual  unity  at  the  outset  of  the  ERP  undertakings  and  because  the  funding  for  the 
ERP  acquisitions  resides  at  the  service  level,  the  services  are  left  working  toward  the 
same  objective  in  different  ways. 

2.  Adopt  Proven  Methodologies 

In  industry,  it  has  been  proven  that  integrating  ERPs  of  separate  organizations  is  a 
much  easier  task  than  integrating  legacy  stovepiped  systems.  This  fact  is  evidenced  by 
the  trend  of  companies  migrating  from  ERP  to  ERP  II  that  was  discussed  in  Chapter  II. 
While,  it  is  not  ideal  that  the  separate  service  components  and  DLA  are  working  on  their 
ERP  projects  individually,  it  is  the  reality  of  the  situation.  Thus,  the  best  that  can  be 
hoped  for  is  the  successful  implementation  of  the  current  projects  and  the  future 
integration  of  these  projects.  The  numerous  examples  from  industry  (also  in  Chapter  II) 
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where  ERP  integration  has  been  a  proven  recipe  for  success  are  the  reason  for  the  trust 
that  the  DOD  has  placed  in  the  future  interoperability  of  the  separate  ERPs.  However,  to 
attain  the  vision  of  an  ERP  enabled  and  integrated  logistics  environment,  the  service 
components  are  going  to  have  to  abandon  certain  practices  common  to  the  military  and 
embrace  the  successful  ERP  methodologies  verified  in  industry  while  avoiding  the  ERP 
pitfalls. 


3.  Past  Mistakes 

Chapter  II  presented  pilot  projects  as  a  beneficial  way  of  testing  the  organizational 
redesign  that  an  ERP  entails  prior  to  translating  the  redesign  across  the  entire 
organization.  It  is  a  risk  reducing  approach  because  a  pilot  proposes  easy  termination  if  it 
is  determined  that  the  project  is  not  going  to  meet  expectations.  For  an  organization  that 
is  adverse  to  risk  like  the  U.S.  Navy,  this  seemed  like  the  perfect  route  to  success  when 
they  started  the  four  ERP  pilot  projects  in  1998.  However,  the  initial  framework  that  the 
Navy  set  their  pilot  programs  up  in  steered  the  project  toward  trouble  from  the  start. 

Technochange  experts  recommend  that  only  one  or  two  pilot  projects  be  initiated 
[33],  The  first  major  mistake  of  the  Navy  was  to  go  against  this  recommended  number  of 
pilots.  Instead  of  one  or  two,  the  Navy  started  the  four  pilots  outlined  in  Chapter  III. 
Each  of  the  pilots  was  independently  headed  by  the  Commanders  of  the  separate 
SYSCOMS  and  no  manager  was  put  in  place  to  oversee  the  projects  as  one  initiative. 
The  choice  to  not  establish  a  single  point  of  contact  to  supervise  the  Navy’s  ERP  program 
does  not  follow  the  principles  for  transitioning  to  an  ERP  that  have  been  set  by  industry 
and  technochange  guidance  which  advocates  that  a  “strong  man”  has  to  be  part  of  the 
effort.  While  the  Commanders  of  the  separate  SYSCOMS  are  high  ranking  naval 
officers,  when  comparing  the  Navy  to  a  corporation,  they  do  not  equate  to  the  Chief 
Operating  Officer  and  can  thus  be  considered  middle  management.  Furthermore,  the 
spreading  of  responsibility  for  a  high  risk  project  amongst  several  leaders  is  a  common 
practice  of  the  Navy  headship.  The  purpose  of  the  practice  is  to  avoid  a  single  agency 
head  being  identified  or  held  accountable  for  cost  overruns  or  a  project’s  failure.  It  is 
evidenced  by  the  manner  in  which  the  Navy  handles  its  shipbuilding  budget.  The  current 
headlines  state  that  multiple  shipbuilding  programs  have  repeatedly  busted  their  budget 
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and  the  “...House  Armed  Services  Committee  wants  to  know  who  to  blame”  [75],  This 
desire  by  Congress  to  find  someone  to  be  responsible  for  the  shipbuilding  program  has 
led  to  an  amendment  to  the  2007  Defense  Authorization  Act  that  requires  the  Navy  “top 
brass”  to  take  responsibility  for  it. 

Unfortunately  for  the  Navy  ERP  program,  there  was  no  such  amendment  looking 
out  for  its  best  interest  back  in  1998  and  the  four  pilots  began  with  no  overarching 
structure  to  resolve  differences  and  steer  the  project  in  a  unified  direction.  In 
technochange  and  transformational  change  efforts,  a  “strong  man”  that  exhibits  strong 
leadership  is  critical  for  success.  The  literature  surrounding  both  types  of  change  states 
that  solid  leadership  is  an  indispensable  element  that  must  be  present  to  move  the  change 
process  forward.  Without  “...  new  leader[s],  great  leader[s],  or  change  champions”  it  is 
highly  probable  that  the  intended  transformation  will  fail  [76],  Continuity  of  these 
change  champions  is  also  an  essential  element  to  see  the  change  through  to  completion. 
The  type  of  transformational  change  that  an  ERP  brings  about  takes  time.  Military 
officers  in  key  positions  to  influence  major  change  only  stay  in  those  positions  for  two  to 
four  years.  This  rotation  schedule  can  kill  the  momentum  of  an  ERP  project  if  the 
follow-on  leader  does  not  place  the  same  amount  of  emphasis  on  the  program  that  the 
previous  leader  did. 

The  Navy  ERP  pilots  did  not  have  a  “strong  man”  and  it  took  a  heavy  toll  on  the 

program  because  the  functional  overlap  between  the  pilots  was  ignored  by  the 

management  teams  [77],  The  overlap  is  a  result  of  the  fact  that  the  SYSCOMS  have  a 

tremendous  amount  of  commonality  and  their  leadership  refused  to  acknowledge  this 

fact.  For  example,  as  was  stated  previously,  military  equipment  has  common 

characteristics  such  as  national  stock  number,  part  number  and  nomenclature.  All  the 

pilots  dealt  with  military  equipment  in  some  form  or  other  and  the  individual  pilot 

leadership  chose  to  ignore  this  commonality  vice  embrace  it.  “Instead,  the  Commanders 

of  the  SYSCOMS  and  the  project  managers  directing  the  projects  evolved  the  pilots  into 

programs  and  shifted  the  emphasis  from  a  trial  to  a  project  which  was  to  be  completed 

and  implemented.  A  competition  ensued  over  which  command  could  get  their  ERP  up 

and  running  first.  To  remain  on  schedule,  inter-project  cooperation  was  discouraged 

which  led  to  a  lack  of  formalization  on  the  format  of  common  data  and  processes  that 
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should  be  followed  in  the  accomplishment  of  tasks”  [77],  Without  an  overarching 
leadership  structure  to  manage  the  pilots,  there  was  no  way  to  force  cooperation  and  the 
pilots  drifted  further  and  further  apart  in  their  approaches. 

The  Navy  contends  that  four  pilots  were  started  because  it  was  believed  that  doing 
one  implementation  for  all  the  SYSCOMS  was  too  large  of  an  undertaking  to  be 
successful  and  rationalized  the  pilots  by  asserting  that  they  were  designed  solely  to  test 
the  functionality  of  an  ERP  within  the  Navy  [77].  Having  multiple  pilots  was  a  way  to 
reduce  the  risk  and  gave  each  of  the  pilots  a  better  chance  for  success.  It  is  true  that 
pilots  are  a  good  way  to  reduce  risk  because  they  provide  users  “hands-on”  experience 
with  the  new  processes  and  allow  for  feedback  on  where  improvements  need  to  be  made 
before  the  pilot  is  expanded  to  other  parts  of  the  enterprise.  However,  it  can  be 
contended  based  upon  the  way  the  Navy  handled  the  shipbuilding  prior  to  2007,  that  four 
pilots  were  started  because  it  provided  for  a  spread  of  responsibility  in  the  event  that 
someone  was  going  to  be  held  liable  for  cost  overruns  or  failure.  Had  only  a  single  pilot 
been  started  at  one  of  the  SYSCOMS,  it  would  have  demonstrated  how  the  selected  ERP 
(SAP  R/3  in  the  case  of  the  Navy’s  pilot  programs)  would  handle  the  common  data  and 
processes  of  all  the  SYSCOMS.  Better  yet,  all  the  SYSCOMS  could  have  sent 
representatives  to  work  on  a  single  pilot  to  negotiate  the  proper  format  for  the  common 
data  and  processes. 

In  industry,  a  conglomeration  of  representatives  from  the  different  functional 

areas  that  come  together  and  are  responsible  for  configuring  an  ERP  are  known  as  a  core 

team.  A  solid  core  team  that  has  both  business  and  technical  knowledge  has  proven  to  be 

a  vital  factor  to  successfully  configure  an  ERP  [78].  Then  again,  this  arrangement  would 

have  required  a  single  high  ranking  representative  from  the  Navy  to  hear  out  the  separate 

arguments  within  the  core  team  and  make  determinations  in  the  best  interest  of  the  Navy 

as  a  whole.  Regrettably,  all  of  the  senior  Navy  personnel  and  project  managers  were 

unwilling  to  leave  their  roles  as  managers  to  take  on  a  role  as  a  leader.  There  is  a 

difference  between  a  manager  and  a  leader  because  “management’s  mandate  is  to 

minimize  risk  and  to  keep  the  current  system  operating.  Change,  by  definition,  requires 

creating  a  new  system,  which  in  turn  always  demands  leadership”  [76],  Furthermore,  it  is 

probable  that  if  only  one  pilot  had  been  started  instead  of  four  and  it  was  ruled  a  failure  or 
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had  some  cost  overruns,  nobody  would  have  been  held  accountable  because  that  is  the 
purpose  of  pilots.  They  are  by  their  very  nature  tests  of  whether  a  proposed  solution  is 
viable  or  not.  The  ingrained  protectionist  attitude  and  competition  between  peers 
exhibited  by  the  pilot’s  management  teams  led  to  a  pilot  structure  that  prevented  any 
possibility  for  success  and  deplorably  wasted  a  huge  sum  of  taxpayer’s  money  in  doing 
so.  “Problems  with  the  structure  and  the  commonality  of  the  pilots  was  addressed  with 
the  program  managers  but  it  was  judged  to  be  mutinous  commentary”  [77]. 

The  decision  to  use  multiple  pilots  instead  of  a  single  pilot  was  a  big  mistake  but 
it  was  not  the  only  mistake  made  in  the  early  stages  of  the  Navy  ERP.  Using  a 
prototyping  approach  also  proved  to  be  a  hazard  to  the  project  because  the  user 
involvement  led  to  an  attempt  to  align  the  prototype  with  the  old  business  processes 
which  is  ERP  pitfall  number  one:  overcustomization.  Private  companies  that  had  core 
teams  who  made  attempts  at  layering  their  old  business  processes  within  the  mold  of  an 
ERP  discovered  it  is  a  fruitless  job.  Legacy  systems  allowed  for  process  customization 
because  they  were  coded  according  to  the  processes  of  individual  industries.  The 
processes  were  in  existence  before  the  legacy  system  came  about  and  the  legacy  system 
came  into  being  as  an  automation  tool  for  those  processes.  This  is  fundamentally 
different  than  an  ERP  which  is  a  template  that  has  certain  structural  elements  that  should 
not  be  changed.  Those  elements  exist  to  help  organizations  implement  standard  business 
processes  across  the  spectrum  of  operational  divisions.  The  templates  also  make  it 
impossible  to  avoid  a  revision  of  processes  during  implementation.  If  the  users  who  are 
involved  in  the  prototype  are  reluctant  to  re-engineer  business  processes  to  conform  to 
the  ERP,  the  implementation  of  the  ERP  runs  a  high  risk  of  failure  [79]. 

All  of  the  service  components  within  the  DOD  can  be  defined  as  mechanistic 

organizations.  “The  ideal  model  of  the  mechanistic  organization  is  one  of  efficiency  and 

predictability,  hierarchically  ordered,  in  which  planning  and  decisions  occur  at  the 

strategic  apex  and  are  implemented  at  lower  levels”  [80].  A  hallmark  of  such  an 

organization  is  a  culture  that  resists  change.  In  essence,  the  service  members  who  are  in 

the  Navy  are  the  Navy  and  undeniably  part  of  the  culture.  The  ideal  model  is  an  exact 

description  of  the  best  way  to  bring  about  change  in  a  mechanistic  organization.  Drive  it 

from  the  top.  If  members  of  a  mechanistic  organization  are  not  forced  to  change  by  the 
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leadership,  they  will  naturally  resist  it  because  of  the  culture.  The  level  of  commitment 
the  Navy  leadership  extended  toward  the  ERP  pilots  has  already  been  addressed.  Given 
the  context,  when  asked  to  make  concessions  to  the  ERP’s  way  of  doing  business,  the 
users  guiding  the  prototypes  in  the  pilot  programs  said  no  and  there  was  nobody  there  to 
make  them  change  their  minds  [77],  Of  course,  implementing  an  ERP  which  has  been 
designed  to  operate  in  the  corporate  world  where  money  does  not  expire  at  the  end  of  the 
fiscal  year  or  have  numerous  policies  dictating  how  it  is  spent  does  have  its  inherent 
challenges.  Also,  the  ERPs  of  the  late  1990s  were  not  as  flexible  and  did  not  support  the 
open  architecture  standard  that  they  do  today.  Nonetheless,  it  was  not  these  challenges  in 
their  entirety  that  led  to  the  weaknesses  of  the  Navy’s  pilots.  Could  it  be  argued  that  they 
were  a  contributor?  Definitely!  Yet,  a  larger  contributor  to  the  shortcomings  of  the  pilots 
was  the  inability  of  the  users  to  change  and  a  lack  of  commitment  by  the  leadership  to  the 
proposed  change  [77], 

At  the  conclusion  of  the  pilots,  the  U.S.  Government  Accountability  Office 
(GAO)  categorically  ruled  the  pilots  a  failure.  They  declared  that  what  had  been  created 
was  “...four  more  DOD  stovepiped  systems  [systems  incapable  of  interoperability  that 
serve  a  single  function]  that  did  not  enhance  the  DOD’s  overall  efficiency  and  resulted  in 
$1  billion  being  largely  wasted”  [45].  The  Office  of  the  Under  Secretary  of  Defense  for 
Acquisition  Technology  and  Logistics  defended  the  pilots  arguing  that  “The  Department 
views  the  pilots  as  successful,  exceeding  initial  expectations,  and  forming  the  foundation 
upon  which  to  build  a  Navy  Enterprise  solution”  [45],  As  presented  in  Chapter  III,  the 
Navy  is  currently  working  on  the  integration  of  the  work  completed  on  the  pilots  to  create 
a  converged  ERP  solution.  The  GAO  contends  that  by  creating  a  converged  solution,  the 
Navy  is  essentially  starting  their  ERP  over  [45].  To  implement  the  Navy’s  converged 
ERP,  the  GAO  also  contends  that  is  going  to  take  another  $800  million  and  it  will  not  be 
operational  until  2011  [45], 

4.  New  Plan 

In  2004,  the  Navy  published  an  integration  white  paper  that  outlines  the 
architecture  for  the  converged  solution  [47],  The  information  contained  within  that  paper 
highlights  the  problems  the  Navy  created  for  itself  by  using  multiple  pilots.  It  states,  “If 
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the  Navy  were  implementing  with  no  existing  ERP  solutions,  the  implementation  strategy 
would  be  different,  but  the  existing  projects  demanded  careful  architectural  planning  in 
order  to  minimize  re-work  and  reduce  risk  to  the  fleet”  [47].  It  further  states,  “The  Navy 
initiated  multiple  pilot  projects  in  2000,  and  the  pilot  projects  were  successful,  but  they 
provided  localized  solutions  as  opposed  to  an  integrated  solution  for  the  Navy’s  operating 
forces  (i.e.  the  fleet)”  [47].  Lastly,  it  states,  “Adoption  of  common  business  processes 
across  maritime  and  aviation,  which  requires  re-work  in  one  or  both  solutions”  [47].  This 
sentence  emphasizes  the  fact  that  by  having  separate  processes  for  the  same  tasks,  the 
Navy’s  ERP  is  going  to  have  to  be  re-worked.  All  of  these  sentences  are  in  a  document 
produced  by  a  contractor  working  for  the  Navy  and  they  still  can  not  evade  the  truth  that 
by  using  multiple  pilots  with  no  long  term  planning  and  cooperation  to  integrate  the 
pilots,  a  problem  resulted  and  a  lot  of  money  and  work  is  going  to  have  to  go  into  fixing 
it. 

It  is  clear  from  the  GAO  report  on  the  Navy’s  pilots  [45]  and  from  the  Navy’s 
own  documents  that  the  way  the  pilots  were  structured  created  problems.  The  questions 
that  surfaces  from  the  debate  between  the  GAO  and  Navy  are: 

•  How  much  did  the  pilots  actually  cost? 

•  What  functionality  will  the  converged  ERP  deliver? 

•  When  will  it  be  complete? 

In  the  case  of  this  debate,  it  is  clear  that  the  two  organizations  are  taking  very 
different  positions  and  the  real  answers  to  these  questions  most  likely  lie  somewhere  in 
the  middle.  Therefore,  the  DOD’s  Business  Transformation  Agency  (BTA)  was 
consulted  to  provide  and  independent  third  party  analysis  on  the  issues.  The  GAO  stated 
that  the  pilots  cost  $1  billion  [45],  Contrarily,  the  Navy  says  that  “35%  or  350M  of  the 
$1B  referred  to  in  the  draft  was  for  investment  in  the  development  of  the  pilots,  while 
55%  was  for  operating  and  support  expenses,  and  the  remaining  10%  for  the  early 
definition  of  the  converged  Navy  ERP  solution”  [45],  For  the  period  through  Fiscal  Year 
2006,  the  BTA  is  advertising  that  the  Navy  ERP  cost  $859.7  million  [81].  This  figure 
supports  the  argument  that  to  date,  the  Navy  has  spent  close  to  a  $1  billion  on  the  ERP 
including  the  pilots.  The  BTA  further  supports  the  GAO’s  prediction  that  through  2011 
the  Navy  ERP  will  cost  another  $800  million.  Including  the  Fiscal  Years  2007,  2008,  and 

87 


2009,  the  BTA  has  a  figure  of  $683.1  million.  Carrying  the  trend  out  two  more  years  to 
2011  validates  the  GAOs  claim  that  the  cost  will  be  somewhere  near  $800  million. 

Functionally,  the  converged  system  that  is  in  development  is  similar  the  Army’s 
Logistics  Modernization  Program  (LMP).  When  the  convergence  is  complete  the  Navy 
will  have  an  ERP  to  cover  the  wholesale  level  of  supply. 


NALCOMIS  OMA 


NALCOMIS  OOMA 


Materials 

(  —rt—  )  Management 

SPS 

DAMIRS** 

CCR 

FLIS 

STARS  FRS 
DAAS 
DDRS 


NALCOMIS  OMA 


NALCOMIS  OOMA 


Plant 
Maintenance 


DC  PS 
One  Pay 
MOCAS 
DDRS 

STARS  FRS 
WAWF 

Management  CZ  daas 


Financial 


Workforce 

Management 


Wholesale 

Supply/APS 


FUS 


Figure  4.2.  Navy  ERP  Interfaces  (From:  [4]) 

For  the  retail  portion,  the  current  plan  calls  for  the  legacy  systems  (UADPS,  NALCOMIS 
OOMA,  CAV,  One  Touch,  etc.)  to  remain  in  place  and  be  interfaced  to  the  ERP.  This 
relationship  is  depicted  in  the  materials  management  portion  of  Figure  4.2.  The  ERP 
“deployment  sites  include  fleet  maritime  and  aviation  intermediate-level  maintenance 
activities  ashore  and  major  Navy  systems  commands  and  their  associated  warfare  centers 
and  field  activities”  [82],  In  the  integration  white  paper,  there  is  a  mention  that  “The 
Navy  plans  to  deploy  SAP  on  its  warfighting  vessels”  which  can  be  considered  the  retail 
level  for  the  seagoing  service.  However,  there  is  no  formal  program  in  place  like  GCSS- 
Army  or  GCSS-MC.  For  the  time  being,  the  focus  is  integration  of  legacy  retail  systems 
into  the  wholesale  ERP. 
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The  timeline  of  201 1  established  by  the  GAO  is  vague  so  the  BTA  was  referenced 
to  confirm  what  the  actual  timeline  is  for  the  Navy  ERP.  Based  upon  what  is  being 
publicized  by  the  BTA,  the  Navy  ERP  will  reach  full  operational  capability  (FOC)  in  the 
Spring  of  2013  [81]. 

D.  A  DIFFERENT  TACTIC 

Since  the  Navy  ERP  is  functionally  similar  to  the  Army  LMP  and  both  programs 
got  underway  in  the  late  1990s  using  the  same  SAP  solution,  it  is  important  to  analyze  the 
reasoning  behind  the  different  approaches.  The  method  the  Army  chose  for  their 
technochange  was  riskier  than  the  Navy’s  because  they  did  not  elect  to  go  with  a  pilot  or 
prototype.  Instead,  the  Army  selected  the  “...traditional  design  first  then  implement 
approach”  [33],  This  approach  is  preferred  by  the  companies  implementing  an  ERP 
because  it  is  much  less  time  consuming  than  the  prototyping  approach  [33],  It  is  riskier 
because  the  expected  results  of  the  ERP  customer  are  not  often  achieved  and  the 
organizational  problems  with  the  software  that  stem  from  the  lack  of  user  involvement 
are  numerous.  This  reality  was  thoroughly  documented  in  Chapter  II.  Nonetheless,  the 
Army  was  willing  to  take  this  risk  primarily  because  it  was  the  recommended  path  to 
follow  by  their  integrator  (CSC).  Integrators  of  ERPs  recommend  the  design  then 
implement  approach  to  corporations  because  a  speedier  approach  equates  to  a  less  costly 
venture.  In  the  corporate  world,  the  bottom  line  is  the  top  priority  and  companies  are  not 
very  receptive  to  lengthy  change  proposals  that  can  quickly  compound  cost  and  run  a 
high  risk  of  failure. 

1.  Organizational  Distinction 

A  speedier  approach  was  attractive  to  the  Army  for  several  reasons.  First,  the 
Army  did  not  have  multiple  organizations  like  the  Navy  responsible  for  the  procurement 
of  supplies.  Unlike  the  Navy’s  aviation  and  a  maritime  branch,  the  Army  has  a  single 
organization  (the  Army  Material  Command)  responsible  for  its  supply  chain.  Secondly, 
the  Army  liked  the  speedy  approach  because  it  is  capable  of  overcoming  several  kinds  of 
resistance.  The  AMC  leadership  recognized  its  role  as  a  mechanistic  organization  and 
understood  that  the  resistance  to  the  ERP  would  be  high.  They  also  recognized  their 
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extensive  power  over  the  organization  and  were  willing  to  use  it.  Wielding  power  to 
force  people  to  accept  change  is  known  as  explicit  coercion.  It  can  be  a  very  powerful 
tool  to  use  in  mechanistic  organizations  where  change  is  never  popular.  The  downside  of 
using  explicit  change  tactics  is  that  they  can  potentially  leave  the  users  at  the  lower  levels 
disgruntled  with  the  change  initiators  [83],  If  explicit  coercion  is  going  to  be  used,  it  has 
to  be  used  quickly  in  order  to  defeat  the  resistance  that  is  common  in  the  BPR 
Organizational  Life  Cycle  of  Chapter  II. 

The  third  reason  the  Army  elected  to  take  the  riskier  approach  was  because  their 
dissatisfaction  with  their  legacy  logistics  operating  environment  was  much  higher  than 
the  Navy’s.  In  change  theory,  there  is  a  formula  which  states:  “Amount  of  Change  = 
(Dissatisfaction  X  Model  X  Process)  >  Cost  of  Change”  [84],  A  summary  of  the  formula 
is  that  the  dissatisfaction  of  the  influential  leaders  with  the  status  quo  must  reach  a  level 
that  the  leaders  decide  that  there  is  no  choice  but  to  change.  This  dissatisfaction  along 
with  a  model  of  the  future  state  of  the  organization  and  the  process  for  how  the 
organization  will  achieve  that  end  state  can  generate  enough  power  to  outweigh  the  cost 
of  making  a  change.  The  level  this  power  needs  to  reach  is  exceptionally  high  because 
the  cost  of  change,  which  is  measured  by  resistance  to  change,  is  significant.  For  the 
Army,  the  dissatisfaction  with  their  logistics  processes  was  at  an  all  time  high  in  the  mid 
1990s  following  the  end  of  the  first  Gulf  War.  In  that  engagement,  the  Army  feared  that 
they  wouldn’t  have  the  supplies  they  needed  so  they  sent  everything  into  theater  and 
created  the  “iron  mountains”  of  unused  equipment  discussed  in  Chapter  I.  It  was 
reported  that  of  the  42,000  containers  that  were  sent  overseas  in  support  of  the  operation, 
the  Army  had  to  open  28,000  of  them  just  to  verify  their  contents  [85].  Despite  the 
proliferation  of  supplies,  the  Army  had  a  remarkably  hard  time  getting  equipment  to  the 
units  that  needed  it,  when  they  needed  it  and  where  they  needed  it.  This  struggle  was  so 
profound  that  it  led  to  a  dissatisfaction  level  that  made  the  Army  more  willing  to  take  a 
riskier  approach  to  their  technochange.  Contrarily,  the  Navy  did  not  have  the  same 
experience  in  the  first  Gulf  War  because  the  Navy  continually  operates  as  a  forward 
deployed  force  in  peacetime  and  in  war.  When  the  ships  (retail  supply  level)  pull  out  of 
their  homeports,  all  the  supplies  they  need  are  onboard  or  they  will  be  replenished  while 
underway.  For  the  Navy,  a  war  in  the  Gulf  simply  meant  it  had  to  change  the  position  of 
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the  majority  of  its  ships  and  concentrate  them  in  one  area.  It  need  not  worry  about  trying 
to  make  a  logistics  system  that  was  designed  to  support  home  based  forces  function 
across  the  globe.  The  Army  did  and  experienced  a  large  amount  of  pain  in  doing  so.  For 
that  reason,  they  were  more  receptive  than  the  Navy  to  the  advice  of  their  integrator  to 
make  their  first  priority  in  their  ERP  the  reengineering  of  their  business  processes  [3], 

Lastly,  the  Army  took  the  riskier  approach  because  as  an  organization  in  the  late 
1990s,  the  Army  was  more  amenable  to  the  inherent  risk  in  change  than  the  Navy.  The 
substantiation  for  this  statement  is  the  Army’s  three  training  centers  at  Fort  Irwin, 
California;  Fort  Polk,  Louisiana;  and  Hoenfelds,  Germany.  During  the  mid  1990s,  the 
training  conducted  at  these  three  bases  encouraged  constructive  conflict  and  decision 
making  at  all  levels.  It  also  expected  straight  talk  between  superiors  and  subordinates 
about  what  went  wrong  and  what  went  right  during  training  evolutions.  These 
discussions  along  with  thorough  after  action  reviews  of  individual  and  group 
performance  created  dissatisfaction  with  the  status  quo  at  all  levels  of  the  Army.  The 
training  experience  as  a  whole  internalized  a  state  of  mind  that  was  a  departure  from  the 
mechanistic  way  of  thinking  in  all  the  soldiers  who  went  through  it.  Soldiers  began  to 
think  of  radical  new  ways  to  solve  problems  individually  and  as  groups  and  the  different 
thought  process  restored  the  Army’s  “cultural  vitality”  [86].  The  training  program  was  so 
progressive  that  it  was  “...studied  by  the  chief  education  officers  at  Shell,  Sears, 
Motorola,  and  GE,  and  by  senior  delegations  from  every  country  in  Western  Europe, 
Russia,  and  most  nations  of  Asia,  Latin  America,  and  the  Middle  East”  [86], 

2.  The  Payoff 

Nobody  can  make  the  claim  that  the  Army  has  had  a  flawless  ERP 
implementation.  In  May  of  2004,  the  GAO  uncovered  problems  with  the  LMP 
“including  such  issues  as  failure  to  follow  necessary  disciplined  processes,  lack  of 
financial  system  integration,  and  system  deployment  slippage”  [1].  Nevertheless,  the 
level  of  criticism  directed  at  the  Navy  ERP  program  is  much  higher  because  when  the 
systems  are  put  side-by-side,  the  Army  has  made  more  progress  in  less  time  and  at 
substantially  less  cost  by  choosing  the  “design  then  implement”  approach.  Both  systems 
perform  the  same  function  for  their  service  components.  Yet,  since  it  initiation  through 
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Fiscal  Year  2009,  the  Army’s  LMP  cost  stands  at  $1.06  billion  [87],  For  the  same  period, 
the  Navy’s  ERP  total  cost  comes  to  $1.54  billion  [81].  The  LMP  went  live  in  July  of 
2003  [87].  In  October,  2007  the  Navy’s  converged  solution  is  scheduled  to  go  live.  Four 
years  behind  and  close  to  $500  million  more  for  the  same  system. 

E.  CHANGE  OR  DIE 

DLA’s  BSM  is  similar  to  the  Army’s  LMP  in  that  DLA  also  chose  to  follow  the 
“design  then  implement”  approach  and  has  found  success  with  it  having  achieved  FOC  in 
2006.  Taking  the  comparison  beyond  this  top  level  is  not  worthwhile  because  the  BSM 
does  not  serve  the  same  function  as  the  LMP  and  the  Navy’s  ERP.  The  BSM  is  not 
concerned  with  the  acquisition  of  major  weapons  systems  and  the  wholesale  level  of 
supply  for  those  systems.  Rather,  it  was  acquired  to  secure  DLA’s  position  as  the 
consumable  supplier  to  the  service  components. 

In  the  late  1990s,  corporations  such  as  Wal-Mart  were  creating  value  and  cutting 
cost  by  eliminating  central  purchasing  departments.  Removal  of  such  intermediary 
departments  was  made  possible  through  the  sharing  of  retail  information  directly  with 
suppliers  [88],  When  viewed  from  the  corporate  perspective,  DLA  is  a  central 
purchasing  department  for  the  consumable  parts  the  DOD  requires.  Thus,  when  the  trend 
went  toward  ERP  in  the  Army  and  the  Navy,  DLA  recognized  the  possibility  that  if  they 
did  not  provide  their  customers  (the  service  components)  a  modem  IT  system  to  plug 
their  ERPs  into,  the  customers  could  bypass  DLA  and  interface  directly  with  the  vendors 
for  consumable  parts.  Such  a  scenario  would  eliminate  the  need  for  a  DLA.  This 
prospect  gave  birth  to  the  BSM  and  the  BSM  along  with  the  agency’s  ERP  II  initiatives 
has  secured  DLA  a  position  in  the  future  of  DOD  logistics. 

F.  THE  BENEFICIARIES 

From  the  Army,  Navy  and  DLA  ERP  projects,  both  the  ERP  vendors  and 
integrators  gained  a  large  body  of  knowledge  about  how  to  structure  an  ERP  for  the  U.S. 
military.  This  knowledge  has  been  applied  to  the  ERP  vendors’  military  templates  and 
the  Marine  Corps  and  Air  Force  is  now  capitalizing  on  the  lessons  learned  and 
investments  made  in  the  Army,  Navy  and  DLA  programs.  For  the  Marine  Corps,  it  took 


92 


the  supply  chain  problems  of  Operation  Iraqi  Freedom  I  to  drive  the  dissatisfaction  with 
the  current  processes  to  a  level  where  the  Corps’  leadership  was  forced  to  remedy  the 
situation  [89].  After  deciding  that  the  time  had  come  to  adopt  an  ERP,  it  appears  that  the 
Corps  absorbed  the  lessons  from  the  Navy  pilots  because  the  highest  ranking  Marine  (the 
Commandant  of  the  Marine  Corps)  is  taking  the  position  of  “strong  man”  for  the 
initiative.  Furthermore,  the  Corps’  transformation  plan  of  focusing  on  people,  processes 
and  technology  demonstrates  a  clear  understanding  that  managing  the  change  that  people 
are  going  to  experience  as  a  result  of  the  ERP  is  as  important  as  the  ERP  itself.  A 
commitment  to  changing  business  processes  is  also  equally  important  because  to  work 
within  the  confines  of  an  ERP  template,  an  organization  can  not  hold  on  to  old  processes. 
Lastly,  by  planning  for  the  GCSS-MC  to  rely  on  DLA’s  NIMS  system,  the  Army’s  LMP 
and  vendors  to  manage  the  majority  of  the  Marine  Corps  material,  the  Corps  is 
demonstrating  a  profound  understanding  of  the  capabilities  that  modem  supply  chain 
management  practices  can  deliver. 

The  Air  Force  intentionally  waited  to  see  how  the  ERPs  of  the  other  service 
components  and  DLA  were  working  before  making  any  decisions  on  the  topic  [90],  It  is 
apparent  that  the  Air  Force  liked  what  they  saw  in  GCSS-MC  because  they  are  following 
an  implementation  plan  that  emulates  the  Marine  Corps’.  Like  the  Marine  Corps,  the  Air 
Force  has  chosen  the  Oracle  e-business  suite  ERP  and  has  also  elected  to  have  a  single 
system  handle  the  entire  supply  chain  from  end-to-end  [66].  It  is  an  approach  that  has 
paid  off  for  the  Air  Force  because  through  Fiscal  Year  2009,  the  ECSS  system  is 
projected  to  cost  $694  million  [70],  By  waiting  on  the  results  of  the  other  ERP  projects 
and  making  the  decision  to  have  a  single  system  control  the  retail  and  wholesale  levels, 
the  Air  Force  is  projected  to  have  a  more  capable  system  for  a  little  more  than  half  the 
cost  of  the  Army’s  LMP  and  a  third  of  the  cost  of  the  Navy’s  ERP. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSION 

ERP  in  the  DOD  started  in  order  to  achieve  compliance  with  the  Federal  Financial 
Management  Improvement  Act  of  1996  (FFMIA)  and  fix  the  supply  chain  problems  of 
the  first  Gulf  War.  An  organization  with  a  long-established  “push”  supply  process  was 
looking  to  institute  “pull”  supply  processes. 


Push 

Pull 

Active 

Resources  scheduled 
Logistics  anticipates 
Less  efficient 
Based  on  estimate  of 
Consumption  due  to 
Operational  tempo 

Reactive 

Resources  requested 
Unit  anticipates 
More  efficient 
Based  on  actual 
consumption  rate 

Figure  5.1.  Push  Vs.  Pull  Distribution  (From:  [91]) 

“Pull”  supply  chain  management  practices  operate  by  the  principal  that  the  production 
and  distribution  of  supplies  is  a  single  process  and  tremendous  efficiency  gains  can  be 
had  by  keeping  inventory  continuously  moving.  Waste  is  created  when  supplies  are  kept 
in  storage.  Therefore,  the  chain  of  events  that  must  take  place  to  get  finished  goods  into 
the  hands  of  the  end  users  has  to  be  integrated  so  that  there  is  a  minimum  amount  of 
storage  at  any  stage.  Automated  Information  Systems  (AIS)  that  share  demand  schedules 
and  production  completion  dates  with  every  member  in  the  supply  and  distribution 
pipeline  are  a  critical  enabler  of  “pull”  logistics.  For  most  organizations  that  operate  a 
according  to  “pull”  principles,  the  AIS  of  choice  is  an  ERP  [10]. 
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Following  the  first  Gulf  War,  the  DOD  began  to  recognize  the  enormous  gains  in 
efficiency  that  private  sector  organizations  were  achieving  with  “pull”  supply  chain 
management  practices  and  ERP  systems.  However,  it  took  the  FFMIA  mandate  and  the 
vision  of  “focused  logistics”  to  encourage  action  by  the  Navy,  Army,  and  DLA.  This 
thesis  examined  the  ERP  programs  of  the  Navy,  Army,  and  DLA  as  well  as  those  of  the 
Marine  Corps  and  Air  Force.  Additionally,  an  analysis  of  the  ERP  experiences  of 
corporate  organizations  was  conducted  so  that  a  comparison  could  be  made  between  the 
most  successful  ERP  implementations  of  the  public  sector  and  the  DODs 
implementations.  This  comparison  revealed  that  the  corporations  that  are  able  to 
maximize  the  capabilities  offered  in  an  ERP  are  the  ones  that  acknowledge  and  address 
the  ERP  pitfalls  outlined  in  Chapter  II  and  embrace  conceptual  unity  amongst  all  the 
divisions  within  their  organization.  By  embracing  conceptual  unity  and  establishing  a 
true  ERP  “strong  man”,  the  most  successful  organizations  are  able  to  place  the  ERP  in  the 
highest  possible  context  and  integrate  all  departments  so  that  data  can  be  matched,  cross- 
matched,  and  shared  throughout  the  organization.  Placing  the  ERP  as  a  top-level 
initiative  eliminates  wasteful  duplication  and  provides  the  organization  a  complete 
enterprisewide  application. 

Without  an  overarching  framework  to  guide  the  DOD  as  an  enterprise  toward  a 
single  ERP  implementation,  the  Navy,  the  Army,  and  DLA  started  their  individual  ERP 
programs.  Not  recognizing  the  common  core  business  functions  between  the  service 
components  and  DLA,  the  three  organizations  abandoned  conceptual  unity  in  favor  of 
distinctive  approaches  to  the  same  problem  with  each  choosing  to  define  itself  as  the 
enterprise.  The  Navy  further  subdivided  itself  and  defined  each  individual  systems 
command  as  an  enterprise.  By  not  acknowledging  the  fact  that  the  organizations  that 
have  had  the  most  success  using  an  ERP  are  the  organizations  that  put  the  system  in  the 
highest  possible  context,  the  DOD  missed  the  opportunity  for  an  optimal  solution.  At  a 
time  when  “focused  logistics”  was  in  print  as  the  vision  for  the  future  of  DOD  supply 
chain  management,  the  benefits  of  a  single  ERP  running  all  of  the  Department’s  logistics 
data  should  have  been  apparent.  Unfortunately,  this  foresight  was  lost  amongst  the 
traditional  competition  between  services  for  individual  identity  and  a  funding  plan  that 
put  money  at  the  service  component  level  and  left  it  up  to  the  individual  entities  to  figure 
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out  the  best  way  to  implement  an  ERP.  There  is  a  ray  of  hope  that  the  DOD  is  realizing 
the  mistake  it  made  with  the  recent  example  of  the  Marine  Corps  and  Air  Force  using  the 
same  approach  and  receiving  tremendous  benefit  from  doing  so.  Nonetheless,  even  with 
the  Marine  Corps  and  the  Air  Force  using  the  same  approach  and  the  same  ERP  platform, 
when  all  the  service  components  have  their  systems  fully  operational,  the  DOD  is  going 
to  have  five  stovepipes  that  have  to  be  integrated  to  realize  “focused  logistics”  [4], 

B.  RESEARCH  QUESTIONS 

1.  What  is  an  ERP? 

An  overview  of  what  exactly  an  ERP  system  is  and  how  it  is  implemented  is 
provided  in  Chapter  II.  The  analysis  presented  in  Chapter  II  leads  to  the  conclusion  that 
despite  the  fact  that  the  DOD  missed  a  notional  opportunity  for  an  optimal  ERP,  the 
decision  to  use  ERPs  instead  of  custom  software  to  transform  the  DOD  business  systems 
was  the  right  choice. 


a.  Software  Product  Lines 

On  average,  ninety  percent  of  custom  software  projects  in  the  DOD  are 
failures.  Acquiring  software  that  has  been  developed  using  a  product  line  architecture 
has  a  proven  track  record  of  achieving  success  in  the  DOD  more  than  ninety  percent  of 
the  time  [92],  Software  that  has  been  produced  using  a  product  line  architecture  has  a 
base  platform  from  which  product  lines  are  built  to  capture  the  domain  specific 
components  of  particular  market  sectors.  For  example,  with  an  ERP,  the  base  platform  is 
the  generic  template  that  holds  the  core  functionality  of  the  system.  On  top  of  the  base, 
domain-specific  product  lines  such  as  a  commercial  line,  a  military  line,  and  an 
educational  line  are  built  to  market  to  those  specific  market  segments.  Taking  the 
architecture  one  step  further,  each  specific  customer  adds  additional  features  to  their 
product  to  meet  specific  needs  that  are  not  in  the  product  line. 
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Figure  5.2.  A  schematic  view  of  an  ERP  product  line  (After:  [93]) 

The  principal  benefit  of  using  product  line  software  is  that  it  allows  for  “...significant 
cost  and  effort  reductions  through  large  scale  reuse  of  software  product  assets  such  as 
architectures,  components,  test  cases  and  documentation”  [93].  Software  product  lines 
are  able  to  reuse  software  product  assets  by  building  off  the  core.  In  the  case  of  an  ERP, 
the  core  is  the  base  template  from  which  all  product  line  templates  are  built.  The  cost  of 
developing  and  maintaining  the  core  is  spread  across  all  the  product  lines  which  translate 
into  lower  cost  for  the  individual  customers.  Another  benefit  of  the  product  line 
architecture  is  quality  is  improved  because  defects  in  the  core  only  have  to  be  fixed  once. 
As  soon  as  a  defect  is  found  and  fixed,  all  the  product  lines  receive  the  benefit  of  an 
improved  core. 

A  final  benefit  of  software  product  lines  is  that  custom  component 
additions  developed  for  individual  customers  can  be  used  by  all  the  customers  in  the 
product  line  who  find  the  component  beneficial.  This  is  important  in  the  context  of  the 
DOD  ERPs  because  if  the  German  military  invest  heavily  in  an  ERP  feature  that  is 
important  to  them,  but,  that  feature  is  also  applicable  to  the  U.S.  customers  in  the  product 

line,  then,  it  does  not  cost  anywhere  near  what  it  would  cost  if  a  single  customer  had  to 

98 


bear  the  burden  alone.  Once  a  custom  feature  is  developed  that  has  a  wider  customer 
base,  it  can  be  placed  in  the  product  line  (the  military  product  line  in  this  case)  and  the 
other  customers  can  purchase  it  for  a  fraction  of  what  it  cost  the  original  customer.  If  a 
feature  has  an  even  wider  audience,  then  it  can  be  rolled  into  the  core  and  all  the  product 
lines  can  profit  from  it.  Furthermore,  the  customers  of  a  product  line  can  collaborate  to 
have  a  feature  developed  for  everyone  in  the  product  line  and  share  the  cost  of  that 
feature.  If  each  customer  were  using  custom  software  that  does  not  follow  a  product  line 
architecture,  this  would  no  be  possible.  They  would  each  have  to  pay  for  whatever 
features  they  want  separately.  This  is  one  of  the  problems  with  the  legacy  systems 
identified  by  the  Army  in  Chapter  III  (lack  of  cost  sharing). 

b.  Established  Architecture 

Requirements  definition  and  system  design  are  the  first  two  stages  of  a 
software  development  project.  Software  design  experts  confirm  that  “Leveraging  known 
solutions  [in  the  design  stage]  minimizes  the  risks  that  an  application  will  fail  due  to  an 
inappropriate  architecture”  [93],  This  is  the  second  reason  that  ERP  was  the  right  choice 
for  the  DOD’s  problems  with  supply  chain  management.  ERPs  have  an  established 
software  architecture  that  has  a  demonstrated  track  record  of  success  integrating  business 
process  to  deliver  the  right  products  to  the  right  place  at  the  right  time  while  at  the  same 
time  accounting  for  the  transactions  properly  and  not  having  accounting  functions  slow 
the  whole  process  down  [94],  A  look  back  at  Figure  3.9  reveals  that  the  business 
processes  that  DLA  was  looking  to  capture  with  their  ERP  are  the  identical  processes  of 
any  intermediary  distributor.  Such  organizations  buy  materials  in  large  lots  and  sell  in 
smaller  lots  to  users  whose  operations  do  not  justify  large  lots.  Frequently,  distributors 
act  as  brokers  and  have  materials  ordered  by  customers  shipped  directly  from  the 
manufacturer  when  the  item  ordered  is  not  held  in  inventory  [10].  By  changing  the 
wording  and  the  pictures  in  the  figure,  the  business  processes  of  amazon.com  or  any  other 
distributor  would  be  depicted.  Consequently,  looking  to  industry  to  find  out  what  IT 
systems  were  helping  some  of  the  “best  in  the  business”  perform  the  distribution  function 
is  the  smartest  thing  DLA  could  have  done. 


99 


2.  By  Industry  Standards,  What  is  the  Optimal  Way  to  Implement  an 
ERP? 

There  are  two  options  that  an  organization  can  choose  from  when  implementing 
an  ERP.  The  first  option  (the  option  the  Army,  DLA,  Marine  Corps,  and  Air  Force 
elected)  is  the  “design  first  then  implement”  approach.  This  is  the  option  corporations 
choose  when  they  have  already  made  the  decision  that  a  switch  is  definitely  going  to  be 
made  to  an  ERP.  It  is  a  faster  path  toward  implementation  because  there  is  no  test  of  the 
ERP  in  a  sector  of  the  organization.  The  “design  first  then  implement”  approach  follows 
the  ERP  life  cycle  outlined  in  Chapter  II  which  starts  with  product  evaluation  and 
precedes  into  implementation  phase  I  and  phase  II. 

The  other  option  an  organization  can  choose  is  the  prototyping  approach  (the 
Navy’s  choice)  which  involves  one  or  two  pilot  projects  to  test  the  organization  redesign 
that  an  ERP  requires  prior  to  translating  the  redesign  across  the  entire  organization. 
Using  the  prototyping  approach  also  starts  with  product  evaluation  but  in  the 
implementation  phase,  only  a  portion  of  the  ERP  is  implemented  such  as  the  operations 
planning  function.  If  that  function  is  deemed  a  success,  then  the  organization  will 
proceed  to  implement  additional  functionality. 

With  either  methodology,  the  organization  that  will  be  most  successful  is  the  one 
that  establishes  a  “strong  man”  for  the  project  who  comes  from  the  highest  level  of  the 
organization  so  that  he  can  resolve  the  conflicts  that  arise  between  the  core  team 
members  representing  the  different  functional  areas.  A  characteristic  that  the  “strong 
man”  must  possess  is  they  have  to  be  open  to  the  business  processes  that  are  resident 
within  the  ERP  so  they  can  ensure  their  organization  avoids  the  number  one  ERP  pitfall: 
overcustomization. 

3.  How  Does  an  ERP  Integrate  Business  Processes  that  are  Not  Part  of 
the  Standardized  Software  Suite? 

The  “strong  man”  has  to  be  open  to  the  business  processes  of  the  ERP  primarily 
so  they  can  make  determinations  about  the  necessity  of  old  business  processes.  They  also 
have  to  be  open  to  the  business  processes  of  the  ERP  so  they  can  instruct  their  team  how 
to  handle  the  situations  where  the  ERP  does  business  differently  than  the  organization. 
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When  this  type  of  situation  is  encountered,  as  was  discussed  in  Chapter  II,  the  RICE 
acronym  is  used.  Again,  RICE  stands  for  reports,  interfaces,  conversions,  enhancements 
and  it  is  the  order  that  solutions  are  sought  to  cover  the  gaps  between  the  functionality  of 
the  legacy  systems  and  the  ERP.  The  first  option,  reports  will  be  used  when  the 
information  that  was  produced  from  a  legacy  system  can  be  generated  as  a  report  out  the 
ERP.  Interfacing  to  a  system  that  has  the  essential  capability  is  the  next  solution.  The 
third  option  is  to  convert  the  data  in  the  old  system  into  a  form  that  the  logic  in  the  ERP 
can  understand.  Finally,  an  enhancement  of  the  ERP  is  the  last  option  that  should  be  used 
because  it  is  a  change  to  the  core  of  the  ERP  to  the  way  business  is  conducted  by  the 
organization.  Despite  the  confusing  vocabulary  that  suggests  an  enhancement  is  a 
positive  action,  it  is  not!  If  an  organization  has  to  resort  to  an  enhancement,  it  generally 
means  that  the  organization  is  clinging  to  the  old  way  of  doing  things  and  is  intending  to 
negate  the  benefits  of  employing  an  ERP.  Every  effort  should  be  made  to  prevent  using 
an  enhancement  as  a  viable  option  [39]. 

Enhancements  are  different  than  an  improvement  that  adds  functionality  to  the 
ERP.  A  good  example  of  an  improvement  is  a  custody  tracking  function  that  is  needed 
for  military  customers.  Adding  this  functionality  to  the  core  ERP  because  it  does  not 
exist  is  an  improvement  that  can  be  sold  to  other  customers  in  the  military  product  line. 
This  is  added  functionality.  Contrarily,  an  enhancement  takes  functionality  out  of  the 
core  software  and  replaces  it  with  software  code  so  that  the  organization  does  not  have  to 
change  the  way  it  does  business. 

4.  What  are  Experiences  and  Plans  of  the  Individual  ERP  Programs? 

The  individual  experience  and  plans  of  each  DOD  ERP  program  to  date  forms  the 
content  of  Chapter  III.  After  wasting  a  billion  dollars  on  the  four  pilot  projects,  the  Navy 
is  attempting  to  converge  the  four  pilots  at  a  cost  of  another  $800  million  into  a  single 
ERP  to  manage  the  Navy’s  wholesale  supply  functions.  The  Navy  is  estimating  that  full 
operational  capability  (FOC)  will  be  achieved  in  the  Spring  of  2013. 

To  meet  the  needs  of  the  Army’s  wholesale  supply  functions,  the  Logistics 
Modernization  Program  (LMP)  went  live  in  July  2003  and  was  certified  FFMIA 
compliant  in  May  2007  [87].  Currently,  the  Army  is  working  on  replacing  the  thirteen 
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legacy  systems  that  manage  the  retail  level  of  Army  logistics  with  the  GCSS-Army  ERP. 
Initial  operational  capability  is  predicted  to  occur  in  October  2010  with  an  FOC  date  of 
January  2014  [54],  If  the  Army  completes  the  GCSS  initiative  and  merges  the  retail 
system  with  the  LMP,  the  vision  of  a  Single  Army  Logistics  Enterprise  (SALE)  will  be  a 
reality.  “The  result  of  implementing  the  SALE  is  a  merger  of  warfighter  and  business 
systems  into  a  single,  harmonious  environment  from  the  manufacturer  to  the  foxhole, 
which  is  aligned  with  joint  requirements”  [54], 

Once  the  Navy  and  the  Army  started  their  ERP  programs  in  the  late  1990s,  DLA 
was  faced  with  the  possibility  that  the  Agency’s  position  as  the  DODs  intermediary 
distributor  would  cease  to  be  relevant  if  the  individual  services  had  the  capacity  to 
connect  their  ERPs  directly  to  vendors  and  streamline  the  supply  chain.  In  response, 
DLA  started  the  Business  System  Modernization  (BSM)  program  in  2000  and  achieved 
FOC  in  late  2006.  Having  achieved  FOC,  DLA  is  working  on  extending  the  enterprise 
with  some  of  the  most  promising  initiatives  in  the  DOD  including  the  Distribution 
Planning  and  Management  System  (DPMS),  the  Integrated  Data  Environment  (IDE),  the 
National  Inventory  Management  Strategy  (NIMS),  the  Global  Stock  Positioning  (GSP) 
system,  and  the  Product  Data  Management  Initiative  (PDMI).  Each  of  these  initiatives  is 
discussed  in  detail  in  Chapter  III.  When  these  projects  are  complete,  DLA  will  be  the 
central  repository  for  all  the  logistics  data  for  the  DOD  covering  in-transit  shipping 
visibility,  unit  location  data,  material  stock  locations,  equipment  technical  data,  and  most 
importantly,  the  NIMS  initiative  will  make  DLA  the  owner  and  manager  of  all 
consumable  material  for  the  DOD. 

By  waiting  on  the  outcomes  of  the  initial  ERP  projects,  the  Marine  Corps  and  the 
Air  Force  have  been  able  to  capitalize  on  the  lessons  learned.  The  plans  developed  by  the 
two  service  components  demonstrate  an  understanding  that  there  is  no  need  to  develop 
separate  ERP  systems  that  perform  the  same  functions.  Product  line  software 
architectures  like  those  of  an  ERP  present  an  opportunity  to  use  the  exact  same  system 
with  each  having  few  additional  improvements  to  handle  the  peculiarities  of  each  service. 
Thus,  the  Marine  Corps  and  the  Air  Force  are  essentially  pooling  their  resources  to  get 
the  best  single  ERP  possible.  FOC  for  GCSS-Marine  Corps  is  anticipated  in  2015  and 

the  Air  Force  has  set  an  ambitious  FOC  date  of  2013  for  the  ECSS  system. 
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5.  What  Are  the  Lessons  Learned  to  Date  that  Will  Assist  the  DOD  in 
Achieving  the  Joint  Vision  for  the  ERP  Programs? 

Having  separate  ERPs  within  the  separate  services  performing  the  same  functions 
is  duplicative.  It  would  be  more  beneficial  if  Figure  5.2  read  U.S.  military,  British 
military,  German  military  for  efficiency  and  cost  but  the  figure  accurately  portrays 
reality.  This  by  no  means  suggests  that  it  was  a  bad  idea  for  the  DOD  to  use  ERPs  for 
business  process  transformation.  The  benefits  of  software  product  lines  and  the 
utilization  of  a  proven  software  architecture  are  good  justification  to  support  the  DOD’s 
decision  to  go  with  ERP  systems.  Moreover,  the  DOD’s  character  as  a  mechanistic 
organization  discussed  in  Chapter  IV  along  with  the  dismal  record  the  Department  has 
with  custom  software  (90%  failure  rate)  rules  out  any  notion  that  custom  software  should 
have  been  used.  Custom  software  may  be  the  answer  for  other  systems  in  the  DOD  but 
that  is  beyond  the  scope  of  this  thesis.  In  the  logistics  arena,  the  DOD  looked  for 
industry  “best  practices”  and  that  equated  to  ERP  [94], 

Besides  the  Navy’s  problems  with  the  first  two  pitfalls  of  an  ERP 
(overcustomization  and  lack  of  top  management  commitment)  and  the  Army’s  problem 
with  pitfall  number  three  (resistance  to  change/lack  of  buy-in  by  the  AMC  programmers), 
a  bigger  problem  has  arisen  as  a  result  of  the  framework  surrounding  the  programs  as  a 
whole.  By  having  these  separate  ERPs  with  overlapping  functions,  the  DOD  has  come  to 
the  realization  that  these  systems  are  going  to  have  to  be  integrated  to  achieve  “focused 
logistics.”  In  order  to  guarantee  that  the  separate  services  work  toward  the  vision  of  an 
integrated  supply  chain,  the  “Deputy  Secretary  of  Defense,  Gordon  England  directed  the 
establishment  of  the  Defense  Business  Transformation  Agency  (BTA)  in  a  memorandum 
effective  October  7,  2005”  [95],  Despite  being  about  nine  years  late,  the  BTA  is  the  best 
solution  for  the  integration  problem.  The  BTA  is  the  overarching  agency  responsible  for 
establishing  the  architecture  and  data  standards  that  the  separate  ERPs  are  to  adhere  to  in 
order  to  ease  the  integration  effort.  As  was  stated  in  Chapter  IV,  in  industry  it  has  been 
proven  that  integrating  ERPs  of  separate  organizations  is  a  much  easier  task  than 
integrating  legacy  stovepiped  systems.  The  task  is  even  easier  if  there  is  a  framework  in 
place  that  specifies  the  data  structure  of  the  components  that  are  going  to  fit  together  in 
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the  framework.  An  institution  to  set  up  a  framework  and  lay  down  the  standards  is  the 
critical  role  that  has  been  missing  from  the  DOD  ERP  programs  and  it  is  finally  being 
fulfilled  by  the  BTA. 


C.  RECOMMENDATIONS 

It  is  going  to  be  more  problematic  for  the  separate  programs  to  adhere  to  the  BTA 
standards  because  the  programs  are  so  far  along  in  their  progress.  Had  the  BTA  been 
established  when  the  programs  got  started  it  is  unlikely  that  the  structure  of  the  ERP 
projects  would  resemble  the  current  situation.  It  is  probable  that  a  central  managing 
agency  would  have  acknowledged  the  fact  that  at  the  same  time  the  DLA  first  explored 
ERP,  the  Navy  and  the  Army  were  also  looking  for  a  better  IT  system  for  the  same 
logistics  process. 
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Figure  5.3.  The  Logistics  Process  (From:  [91]) 

Chapter  III  emphasizes  the  fact  that  the  Army’s  LMP  and  the  Navy’s  ERP  programs 
started  to  buy  new  systems  for  the  acquisition  and  in-service  support  of  weapons  systems. 
At  the  point  in  the  late  1990s  when  the  first  three  programs  got  underway,  had  anyone 
looked  at  the  DOD  as  the  enterprise  from  the  top  down,  they  would  have  realized  that  the 
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plan  to  buy  three  separate  systems  to  aid  with  distribution,  sustainment  and  disposition 
was  a  path  to  three  more  “stovepiped”  systems. 

It  is  here  where  the  DOD  missed  the  opportunity  to  have  an  optimal  ERP 
implementation.  All  the  service  components  acquire  major  weapons  systems  in  the  same 
way.  Therefore,  there  is  only  a  need  for  one  system  to  perform  acquisitions. 
Additionally,  all  military  equipment  is  maintained  in  the  same  way  so  there  is  no  for 
separate  systems  to  perform  that  function  either.  Therefore,  it  is  recommended  that  for 
the  supply  chain  management  operation,  after  major  weapons  systems  are  acquired,  the 
best  process  would  be  for  the  services  to  hand-off  responsibility  for  in-service  support 
(meaning  supply)  and  disposition  to  the  DLA.  That  is  the  difference  between  DLA  as  a 
distributor  and  a  distributor  in  the  commercial  sector.  When  customers  in  the  commercial 
sector  order  items  from  a  distributor  such  as  Amazon.com,  the  customer  isn’t  running 
their  own  ERP.  They  simply  link  into  the  distributors  system  and  order  the  material  that 
is  needed.  As  depicted  in  Figure  3.10,  the  separate  service  components  are  the  customers 
of  the  DLA  who  is  functioning  as  a  distributor.  Currently,  DLA  only  distributes 
consumable  material.  However,  there  is  no  reason  why  they  could  not  handle  repairable 
components  as  well.  While  it  would  be  ideal  if  the  separate  service  components  used  the 
same  acquisition  system,  it  is  not  absolutely  necessary.  The  greatest  potential  to  improve 
the  ERP  programs  is  to  have  the  service  components  keep  the  acquisition  systems  that 
each  is  acquiring  in  the  separate  ERP  projects  but,  in-service  support  and  disposal  should 
be  the  responsibility  of  the  DLA.  Presently,  the  NIMS  initiative  is  guiding  the  DOD  in 
this  direction  for  consumable  material.  A  repairable  material  initiative  should  be  started 
so  that  DLA  handles  the  life  cycle  of  all  material  from  the  time  it  comes  in-service 
through  disposal. 

D.  FUTURE  RESEARCH  POSSIBILITIES 

This  research  focused  on  analyzing  the  lessons  learned  from  industry  that  will 
help  the  DOD’s  ERPs  be  successful.  Additionally,  a  comparison  of  the  separate  service 
component’s  ERP  strategies  was  conducted  to  benchmark  the  programs  against  each 
other  and  against  industry  best  practices  to  provide  the  DOD  a  reference  to  help  the 
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projects  in  the  future.  Some  additional  research  possibilities  generated  by  this  thesis  but 
not  addressed  in  the  document  include: 

•  How  does  an  automatic  identification  method  such  as  radio  frequency 
identification  (RFID)  interact  with  ERPs  and  how  will  the  combination  of 
the  two  capabilities  improve  DOD  supply  chain  management  practices? 

•  What  impact  will  the  ERPs  have  on  the  DOD  manpower  structure? 

•  Given  that  DLA  acts  as  an  intermediary  distributor  for  consumable 
material,  what  changes  would  have  to  be  made  within  the  DOD  to  make 
DLA  responsible  for  all  material,  repairable  and  consumable? 

•  What  are  the  metrics  being  used  to  evaluate  how  well  the  ERPs  are 
performing  as  compared  to  the  legacy  systems  they  are  intended  to 
replace? 
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